What an automated accessibility scanner can and cannot detect
The first thing a business often does about accessibility is run a one-off scan. It runs Lighthouse, receives a score and, if the score is green, considers the subject closed. One number from one run is not the same as an accessible website—and that is often why a site remains inaccessible despite scoring “100”.
What an automated scanner can detect
Automated tools such as axe-core and IBM Equal Access provide a useful foundation. They can identify some issues that can be tested against a rule in the code:
insufficient text contrast, images without alternative descriptions, buttons without accessible names, skipped heading levels, a missing page language, form fields without labels, or selected errors in ARIA attributes. The scope depends on the tool, its rules and the page states available to the check. The run can be repeated following relevant changes.
Where automation reaches its limits
Not every criterion can be read from the code. Some are not about what is present on the page, but whether it makes sense—and only a person can judge meaning. This is a limitation of every automated tool, not only ours:
- Is the alternative text meaningful? Automation verifies that the
altattribute has a value. It does not object if that value isIMG_4271.jpg. - Is the content order logical? It may look right visually, but in the order announced by a screen reader the price may come before the product name. That is a question of meaning, not a technical rule.
- Is the error message understandable? Automation checks that a message exists and is associated with the field. It cannot judge whether “Invalid input” genuinely helps the customer.
This limitation applies to every automated solution on the market. We therefore do not claim that automation covers one hundred per cent of WCAG—no tool can. What can be tested, however, is worth testing properly and continuously.
How to use automated checks sensibly
The question is not whether to use automation, but how to use it. A one-off scan of the home page and continuous automated checks across an application are two different things.
A suitable choice of tool and rules. Tools overlap in part and may apply different rules. More tools are not automatically better; it is important to understand the results, remove duplicates and monitor a consistent baseline.
Across real states. We check common user journeys, not only static pages, so you also receive results from states that appear only during use: after sign-in, in a modal window, after a form is submitted and during checkout. Accessibility often breaks in precisely these states, which a simplistic scan of the home page cannot reach at all.
Continuously and according to risk. Checks can be integrated into CI/CD for relevant changes. They help flag new machine-detectable issues, but they do not replace manual review or guarantee that a previously fixed state will remain unchanged.
The output is a report mapped to the relevant WCAG and EN 301 549 criteria: every finding has a severity and a recommended fix. Developers receive a list of specific tasks, not automatic legal confirmation of compliance.
Why it is worthwhile even without a legal obligation
The European Accessibility Act is one reason to address accessibility, but it is not the only one. An accessible website may be easier to operate on a mobile device, cleaner semantics can also help search engines, and more people can use the service. Some customers will not complain when they encounter a barrier; they will simply abandon the purchase.
Next step
A free initial scan provides a first view of machine-detectable issues. During a no-obligation consultation, we can determine which states are worth checking automatically and which require manual verification.