The European Accessibility Act (EAA) has moved accessibility from “nice to have” to “legal requirement” for a large slice of the digital economy. If you sell to customers in the EU, it’s worth understanding what it actually asks for — because the answer is less daunting than the acronym suggests, and most of it is work that makes your site better for everyone.
What the EAA is, in plain terms
The EAA is EU legislation that requires certain products and services — including e-commerce, banking, transport ticketing and e-books — to be accessible to people with disabilities. In practice, “accessible” means meeting the requirements of the harmonised European standard EN 301 549, which for web content aligns with the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.
Scope matters. The Act applies in full to specific product and service categories; a purely informational B2B marketing site may sit outside its strict legal reach. But treating that as an excuse to skip accessibility is a false economy — the same standard is increasingly expected by customers, procurement processes and search engines regardless of whether a given page is legally in scope. We build every site to WCAG 2.2 AA as a baseline for that reason, and publish an honest accessibility statement for our own.
What WCAG 2.2 AA actually asks for
It’s easy to imagine an intimidating checklist. In practice the requirements cluster into a handful of principles that a well-built site satisfies almost by construction:
- Perceivable. Sufficient colour contrast between text and background. Meaningful images carry descriptive alt text; decorative ones are hidden from assistive technology. Content is readable when text is resized or the page is zoomed.
- Operable. Everything works with a keyboard alone, not just a mouse. The keyboard focus indicator is always visible, so a keyboard user can see where they are. Nothing traps focus or depends on a gesture that some users can’t perform.
- Understandable. A clear, consistent structure and navigation. Form fields have real labels, and errors are announced clearly and tied to the field they belong to.
- Robust. Semantic HTML and, where needed, ARIA, so assistive technology can interpret custom components — an accordion, a menu, a dialog — correctly.
The steps that actually move the needle
The single biggest determinant of whether a site is accessible is when accessibility enters the process. Retrofitting it onto a finished build is expensive and rarely complete; designing for it from the first wireframe costs almost nothing extra. Concretely, that means:
- Design to contrast and focus from the start — not as a post-launch audit fix.
- Build on semantic HTML, adding ARIA only where native elements genuinely fall short.
- Test with a keyboard and a screen reader, by hand — automated scanners catch perhaps a third of real issues; the rest need a person actually navigating the page.
- Write an accessibility statement that’s honest about your conformance level and gives people a way to report problems.
None of these is exotic. They’re the difference between a site that happens to pass a scanner and one a person using assistive technology can actually use — which is the whole point of the legislation.
If you’re weighing up what the EAA means for a site you already run, or building something new and want it right from the first wireframe, that’s exactly the kind of work our web development and UI/UX design teams handle as standard. Accessibility isn’t a phase we get to later; it ships on every build.