The European Accessibility Act: What It Means for Your Site

The European Accessibility Act (EAA) has been in force since 28 June 2025. A year on, the most common reaction we still hear from clients is “that applies to government sites, not us.” It doesn’t. The EAA targets private businesses, and it reaches a lot further than most owners assume.

This is a plain-language walkthrough of who it covers, what “accessible” means once you get past the legalese, and what we actually do when a client asks us to get them compliant.

What the EAA is, briefly

It’s an EU directive that sets common accessibility requirements for a defined list of products and services. The goal was to stop every member state from writing its own incompatible rules. Each country has now transposed it into national law, so enforcement happens at the national level, but the baseline is shared.

The directive is not abstract. For digital services it points at a concrete technical standard, which means “are we compliant?” has a checkable answer rather than a vibe.

Who it actually applies to

This is where the surprises live. Two points catch people out.

It’s about the EU market, not your office address. If you sell products or offer covered digital services to consumers in the EU, the EAA applies regardless of where your company is headquartered. A US or UK business serving EU customers is in scope.

It covers a specific list of services, but it’s a broad list. The ones that touch most websites:

• E-commerce (selling products or services online to consumers)
• Consumer banking and financial services
• Electronic communications services
• Passenger transport services (booking, tickets, real-time info)
• E-books and dedicated reading software
• Access to audiovisual media services

If your site sells something, books something, or handles money for consumers, assume you’re in scope until proven otherwise.

The microenterprise carve-out is narrower than it sounds. Businesses with fewer than 10 employees and annual turnover or balance sheet at or below €2 million are exempt from the EAA’s service obligations. Two catches: the exemption covers services, not products, and it does not help a non-EU business serving the EU market. So “we’re small” is not a reliable shield, and it never was for the company selling physical products.

If you’re not certain which side of the line you fall on, that’s a question for a lawyer in the relevant country, not a blog post. But the safe planning assumption for most consumer-facing sites is: you’re covered.

What “accessible” means in practice

For websites, apps, and digital content, the technical baseline is WCAG 2.1 Level AA, pulled in through the harmonized European standard EN 301 549. WCAG is built on four principles, easy to remember as POUR:

Principle	Plain meaning	Typical failures we find
Perceivable	Users can perceive the content	Low color contrast, missing alt text, no captions
Operable	Users can operate the interface	Keyboard traps, no focus indicator, tiny tap targets
Understandable	Content and UI behave predictably	Unlabeled form fields, vague error messages
Robust	Works with assistive tech	Broken semantics, custom widgets with no ARIA roles

Meeting WCAG 2.1 AA is not exotic. Most of it is the difference between a page built with real HTML semantics and one stapled together from divs and JavaScript.

The parts that fail most often

After auditing a fair number of marketing sites and storefronts, the same five issues account for the bulk of the failures:

1. Color contrast. Light-gray text on white, brand colors used for body copy, placeholder text mistaken for labels. AA needs 4.5:1 for normal text, 3:1 for large text. Check yours with our Color Contrast Checker, and see our contrast and WCAG guide for the details.
2. Missing or lazy alt text. Decorative images need empty alt; meaningful images need descriptive alt; icons that act as buttons need accessible names. Our alt text guide covers the judgment calls, and the Alt Text Checker flags the gaps.
3. Keyboard operability. Try using your site with the Tab key and nothing else. If you can’t reach the menu, complete checkout, or escape a modal, neither can a keyboard or switch user. A visible focus outline is not optional.
4. Forms without labels. Every input needs a programmatically associated <label>. Placeholder-as-label disappears the moment someone types, and screen readers handle it poorly.
5. Custom components with no semantics. Hand-rolled dropdowns, tabs, accordions, and carousels are the usual offenders. If it looks like a button, it should be a <button> or carry the right ARIA role and keyboard handling.

None of these require a rebuild. They require attention.

What enforcement looks like

Enforcement is handled by national market surveillance authorities, and the penalty regime varies by country because each member state wrote its own. In practice, the realistic triggers are a consumer complaint, a competitor or advocacy group filing, or an authority audit. Consequences range from orders to fix, to fines, to (at the severe end) being barred from offering the non-compliant service.

We have not seen a wave of headline fines, and we wouldn’t bet a content strategy on scare tactics. The stronger argument is the boring one: accessible sites convert better, rank better, and are cheaper to maintain because they’re built on solid semantics. Compliance is the floor, not the goal.

A practical path to compliance

This is the sequence we run, and it’s the same one whether the deadline is legal or self-imposed:

1. Automated scan first. Run axe, Lighthouse, or WAVE across key templates. This catches maybe 30-40% of issues instantly: contrast, missing alt, missing labels, basic ARIA. It will not catch everything, and any tool promising “100% compliant, automatically” is selling something.
2. Manual pass on the journeys that matter. Tab through the homepage, a product page, the cart, checkout, and your main forms. Test with a screen reader (VoiceOver on macOS, NVDA on Windows, both free). This is where the real issues surface.
3. Fix in priority order. Blockers first (can a keyboard user complete a purchase?), then perceivable issues (contrast, alt, captions), then polish. Don’t chase a perfect score on a page nobody visits before fixing checkout.
4. Publish what you did. The Act expects providers to make accessibility information available. Practically, that means an accessibility statement: what standard you target, known gaps, and how someone reports a problem. It also signals good faith if a complaint ever lands.
5. Stop it from regressing. Add an accessibility check to your build or QA so the next “quick” component change doesn’t quietly undo the work. Accessibility is not a project you finish; it’s a property you maintain.

Where tools end and judgment begins

Automated checkers are genuinely useful for the mechanical stuff, and you should run them. But accessibility is fundamentally about whether a real person using assistive technology can do what they came to do. A page can pass every automated rule and still be unusable with a screen reader because the reading order is scrambled or the error messages are meaningless.

So: use the scanners to clear the easy failures fast, then spend your manual time on the few journeys that actually earn revenue.

If you want a second pair of eyes, we audit sites against WCAG 2.1 AA and hand back a prioritized fix list rather than a 200-page PDF nobody reads. Get in touch and we’ll tell you honestly where you stand.