Automated accessibility testing: what it finds and what it misses
An automated test checks a page in seconds and finds errors a person would take hours to spot. But it only sees part of accessibility. Here is what it detects well, what it cannot judge and how to use it without being misled.
How an automated test works
A browser loads the page like a visitor, then a rules engine inspects what is displayed: the final HTML, computed styles and ARIA attributes. Odeet uses axe-core, the reference open-source engine, plus its own checks. Each page is tested twice, on desktop and on mobile, because the problems differ.
What it detects well
- Text with too little contrast against its background.
- Images without alternative text.
- Form fields without a label.
- Links and buttons without a name, such as a lone icon.
- A missing or invalid page language.
- Misused ARIA attributes.
- Zoom blocked on mobile and touch targets that are too small.
These are common errors, easy to fix, and often repeated on every page that shares the same template.
What it cannot judge
- Whether alternative text is relevant: “image123.jpg” passes the test but helps no one.
- Reading order and the logic of a checkout journey.
- Full keyboard navigation: a keyboard trap, an inconsistent tab order.
- How clear error messages and instructions are.
- Video captions and transcripts.
- PDF documents and content that changes after an action.
These need a person. That is why an automated test is a pre-audit, not proof of compliance.
How to read a score
The Odeet score starts at 100 and deducts points according to the severity of each issue and the number of elements affected. It is a technical indicator for tracking a site’s progress, not a compliance rate. A score of 100 means no issue was detected automatically, not that the site is accessible.
Five checks to do by hand
- 1Move through the page with the Tab key: every link and button must be reachable, with a visible focus.
- 2Zoom to 200%: nothing should overlap or disappear.
- 3Read the images’ alternative text: does it describe what matters?
- 4Fill in a form with mistakes: does the message say what to fix?
- 5Listen to the page with a screen reader, VoiceOver on Mac or NVDA on Windows.
Using an automated test well
- Test one example of each template: home, list, detail page, form, checkout.
- Fix critical issues and those repeated across many pages first.
- Run the test again after each fix and each release.
- Keep a record over time to show progress to a client or management.
Frequently asked questions
- What share of issues does an automated test find?
- Only part of them, depending on the site: mostly code errors. Problems of meaning and usability need a person.
- Does an accessibility widget make a site compliant?
- No. An overlay added to the site does not fix its code: the problems remain for people using a screen reader or a keyboard.
- Do I need to test every page?
- Not necessarily. Pages built on the same template often share the same errors. A sample covering each template is enough to start.
- Is Odeet’s free test enough?
- It shows the first three issues on a page. A free account analyses up to 20 pages, with the affected elements and fixes.
Test a page of your website
Further reading
- Test a page’s accessibilityFree test on desktop and mobile, no account needed.
- Methodology and limitsWhat Odeet analyses and how the score is calculated.
- Colour contrast: the WCAG and RGAA ratios to meet4.5:1 for text, 3:1 for large text and components: the rules and pitfalls.
- RGAA vs WCAG: what’s the difference?WCAG sets the rules; the French RGAA is the method used to check them.