An automated accessibility audit can identify many website issues within seconds. However, a website that passes an automated test without errors is not necessarily accessible.
Some accessibility issues can be detected automatically. Others require a person to test the website, use keyboard navigation, and go through actual user journeys such as purchasing a product, logging in, or submitting a form.
This is why an effective accessibility audit should not be limited to running a scanner and generating a report.
What can an automated accessibility audit detect?
Automated tools are useful because they can quickly analyse a large number of elements and pages.
They can detect issues related to areas such as:
- text and interface contrast,
- missing or incorrect form labels,
- heading structure,
- some incorrect uses of ARIA attributes,
- missing alternative text for images,
- HTML document structure,
- selected issues affecting the use of assistive technologies.
There are different ways to perform this type of analysis, including online accessibility scanners, tools integrated into development environments, and browser extensions. One example is DockAccess, which can run automated website accessibility audits. We also provide a free extension for Chrome and Firefox that allows developers and testers to check accessibility directly while working with a website.
Browser-based tools can be particularly useful during development and testing. They make it possible to quickly inspect the current page, analyse a specific part of the interface, review the document structure, and identify some accessibility issues before changes reach production.
Another major advantage of automated testing is repeatability. The same set of rules can be checked regularly, making it easier to detect accessibility issues introduced by new changes.
An automated audit therefore works well as a first layer of accessibility testing.
It should not, however, be the last one.
Why isn't an automated WCAG test enough?
Imagine an online store.
The contrast is correct. Buttons have accessible names. Form fields have labels. Images have alternative text. The automated scanner does not report any serious problems.
A user adds a product to the cart and proceeds to select a delivery method. A modal window opens.
And this is where the problem appears.
A person using only a keyboard can enter the modal but cannot leave it. Keyboard focus becomes trapped, making it impossible to complete the purchase.
The individual elements may appear correct, but the overall process does not work.
This is exactly the type of issue that automated tools often cannot evaluate properly.
W3C points out that automated tools cannot check every aspect of accessibility and that their results require interpretation. A report containing no automated errors therefore does not mean that a website is fully accessible.
Source: W3C – Selecting Web Accessibility Evaluation Tools
What does a manual WCAG audit check?
A manual audit makes it possible to evaluate a website from the perspective of someone actually using it.
Instead of checking only an individual button or form field, the tester completes an entire task.
For an online store, this could mean:
searching for a product → selecting a variant → adding it to the cart → choosing delivery → making a payment → confirming the order.
For a SaaS application:
logging in → opening a specific feature → completing a form → handling an error → saving the changes.
This approach can reveal barriers that only become apparent during actual interaction with the website.
A good test scenario should be specific.
Instead of:
Test the shopping cart.
it is better to define the task as:
Add a product to the cart, change the quantity, select a delivery method, and correct an invalid postal code using only the keyboard.
In the second example, it is clear what needs to be tested and when the process can be considered accessible.
Automated or manual accessibility audit?
The best results come from combining both approaches.
Automation provides scale. Human testing provides context.
Automated tests can quickly scan many pages and identify recurring problems. An accessibility auditor can then focus on areas that cannot be reliably evaluated programmatically.
There is therefore no need to choose between automated and manual testing.
Automated tests are useful as a first filter and as part of continuous accessibility monitoring. Manual testing answers a much more important question:
Can a user actually use the website and complete its most important tasks?
Do you need to test every page?
Not necessarily.
A large online store may contain tens of thousands of URLs, but many of them use the same templates and components.
Instead of testing hundreds of nearly identical product pages, an audit can cover representative page types and user journeys, such as:
- the homepage,
- product listings,
- product pages,
- search results,
- the shopping cart,
- checkout,
- contact forms,
- login and registration,
- the user account area,
- more complex or unusual pages.
The key is selecting the right sample.
Testing five similar articles may provide less useful information than testing one complex form that cannot be operated using a keyboard.
W3C describes how to define the scope and select a representative sample of pages in its WCAG-EM methodology.
Source: W3C – Website Accessibility Conformance Evaluation Methodology
What should a good WCAG audit report include?
An accessibility report should not simply be a long list of errors.
Each significant issue should answer several practical questions:
Where does the problem occur?
A specific page, component, or user journey.
How can it be reproduced?
Instructions that allow a developer or tester to see exactly the same problem.
Who does it affect?
An explanation of how the barrier makes the website more difficult or impossible to use.
What requirement does it relate to?
The relevant WCAG success criterion or another requirement used as the basis for the assessment.
How should it be fixed and tested again?
A developer should understand not only what is wrong, but also what the expected result should be.
Priority also matters.
An issue that prevents a customer from completing an order should be treated differently from a minor inconvenience on a rarely visited page.
One issue can appear hundreds of times
It is also worth being careful when looking at the total number of errors in an audit report.
If the same incorrectly implemented component appears on 300 pages, this does not necessarily mean there are 300 independent problems.
It may be one problem in a component that is used 300 times.
From a development perspective, this distinction is important. Fixing the shared component may remove the issue across the entire website.
A useful audit should support decisions like this rather than simply increase the number of items in the report.
What should you do after receiving an accessibility audit?
The report is the beginning of the process, not the end.
First, separate issues that require changes to code, content, or interface design. Then define priorities and start with barriers that prevent users from completing the most important tasks.
After implementing a fix, repeat the scenario that originally revealed the problem.
If a user could not complete a purchase using a keyboard, simply changing the development task status to “Done” is not enough.
The purchase process should be tested again using the keyboard.
Only then can you confirm that the problem has actually been resolved.
How can you start checking your website's accessibility?
You do not need to analyse your entire website at once.
Start by identifying the three most important things users should be able to do on your website. This might be purchasing a product, submitting a form, creating an account, or finding important information.
Run an automated audit to identify issues that can be detected programmatically. You can use tools such as DockAccess or a browser extension for accessibility testing. Then go through the most important user journeys manually, including using the website with only a keyboard.
This alone will give you a much better picture of your website's accessibility than relying only on the result of an automated scanner.
At Dock, we combine automated testing with manual accessibility audits and analysis of key user journeys. Based on this, we can define the scope of an audit, prioritise identified issues, and help implement and retest the necessary improvements.
