EAA compliance tools: what automated checks catch, and what they never will
Search for an "EAA compliance tool" and you get two very different things wearing the same name. One is an automated scanner: it crawls your pages and reports errors it can measure. The other is an overlay widget: a line of JavaScript that promises compliance in a day. They are not the same product, and only one of them is genuinely useful.
This is what each actually does, and what neither of them can do for you.
What the law points at
The European Accessibility Act, Directive (EU) 2019/882, has applied since 28 June 2025. It covers products and services sold to consumers in the EU: e-commerce, consumer banking, e-books, ticketing and check-in machines, transport information, and more.
Here is the part that trips people up. The Act itself does not contain a list of things to test. It sets the obligation and points at the harmonised standard, EN 301 549, which for web content in turn points at WCAG 2.1 level AA. So when someone says "we need to pass the EAA", what they are going to be measured against is WCAG.
The Act adds obligations that WCAG says nothing about: you have to provide information about the accessibility of your service, keep it available, and be able to explain how you meet the requirements. A perfect scanner score does not produce that document.
Where automated scanning genuinely helps
Scanners are excellent at exactly one thing: finding mechanical failures in bulk, across thousands of pages, in minutes. That is not a small thing. If you have 4,000 product pages with a missing form label in a shared template, a scanner finds it in one run and a human never will.
What they reliably catch: missing `alt` attributes, colour contrast below threshold, form controls with no programmatic label, empty links and buttons, a missing `lang` attribute, broken heading order, invalid ARIA roles and references.
But they only see what can be measured mechanically. Every serious study of automated testing puts the share of WCAG issues detectable that way at roughly a third. Not because the tools are bad, but because most accessibility failures are about *meaning*, and meaning is not a property a script can read.
An image with `alt="image1234.jpg"` passes the "has alt text" check. It fails the actual requirement completely. The scanner cannot tell the difference; a person can, in two seconds.
What no tool can decide for you
- Whether the alt text is right. Presence is testable, accuracy is not.
- Whether focus order makes sense. A page can be technically focusable in an order that is unusable.
- Whether a custom component works from the keyboard. Your date picker, your mega menu, your modal. This is where real failures live.
- Whether an error message helps. "Invalid input" is an error message. It is not an accessible one.
- Whether captions match what is said. A caption file exists, or it does not. Whether it is correct is a human judgement.
- Whether the page still works at 200% zoom on a narrow viewport, without content being cut off or trapped.
About overlays
Overlay widgets deserve a direct answer, because they are sold hard and they are the reason a lot of people search for a compliance tool in the first place.
An overlay cannot fix the underlying HTML that a screen reader reads. It sits on top of it. In practice, users of assistive technology report that overlays frequently make things worse, because they interfere with the settings and behaviour the user has already configured. There is a widely signed community statement to that effect, and enforcement bodies have not accepted overlays as a substitute for conformance.
If a vendor offers you legal compliance from a single script tag, treat that as the claim it is. We wrote about this in more depth in the problem with accessibility overlays.
What a working process looks like
- Run the scanner first. It is cheap, fast and clears the mechanical noise so that human time is not wasted on it. Run it in CI so regressions do not creep back in.
- Do a keyboard pass. Unplug the mouse. Tab through your top five user journeys end to end: search, product, cart, checkout, account. If you cannot complete a purchase with the keyboard alone, nothing else on the list matters yet.
- Spot check with a screen reader. NVDA on Windows or VoiceOver on macOS, on the same journeys. You are not auditing everything, you are checking whether the important paths are usable.
- Write the accessibility statement. What conforms, what does not yet, what the workaround is, and how someone reports a problem. This is a legal requirement, and it is also the document that shows good faith if anyone ever asks.
The short version
An automated tool is a necessary part of the process and never the whole of it. It removes the errors that are cheap to find so that you can spend expensive human attention on the ones that actually stop people using your site.
Anyone selling you the whole of it in a script tag is selling you the part that does not exist. If you want a starting point, our EAA compliance checklist walks through the requirements one by one.