Accessible Websites Under the EAA: Who Must Act, and How

Since 28 June 2025, the European Accessibility Act (EAA) has been in force across the EU – in Germany implemented as the Barrierefreiheitsstärkungsgesetz (BFSG). Since then, two extremes have circulated: panic consulting (“every website must be rebuilt immediately!”) and heads in the sand (“doesn’t affect us”). Both are wrong. This article sorts out who the obligation really hits, what’s technically behind it – and why accessibility is a good idea even without a legal mandate.

The usual caveat first: we are developers, not lawyers. This article explains the technical and practical side. Whether your website falls under the EAA in your specific case is a question for legal counsel.

Who the EAA covers – and who it doesn’t

The EAA covers products and services for consumers. For websites, the relevant category is e-commerce services – simplified: anywhere a consumer can buy, book or conclude something online.

Typically in scope:

• Online shops (including small WooCommerce sites with consumer customers)
• Booking and appointment systems
• Customer portals where contracts are concluded or managed
• Websites with ordering or payment functions

Typically out of scope:

• Purely informational websites without purchase or booking functions
• Pure B2B offerings (the EAA protects consumers)
• Micro-enterprises for services: fewer than 10 employees and under 2 million euros annual turnover

Important nuance on the micro-enterprise exemption: it applies to services, not products – and it’s an exemption from the obligation, not a free pass. If the company grows past the thresholds, the obligation grows with it.

What’s required: EN 301 549 and WCAG 2.1 AA

The law itself doesn’t specify pixels and contrast ratios – it points to the European standard EN 301 549, which for web content references the Web Content Accessibility Guidelines (WCAG) 2.1, level AA. That’s the actual benchmark, and it has been established for years.

WCAG organises everything under four principles:

1. Perceivable. Content must be accessible to all senses: alternative text for images, captions for videos, sufficient colour contrast (at least 4.5:1 for normal text), no information conveyed by colour alone.

2. Operable. Everything must work without a mouse: full keyboard operability, visible focus states, skip links, no time limits without extension, no flashing content that can trigger seizures.

3. Understandable. Clear language, consistent navigation, forms with labelled fields and error messages that say what is wrong and how to fix it.

4. Robust. Clean, semantic HTML that assistive technologies can parse reliably – a <button> is a button, not a clickable <div>.

Reading the four principles, one thing stands out: most of this is simply solid craftsmanship. A well-built website meets many AA criteria as a by-product – a badly built one fails almost all of them.

The most common problem areas in practice

Audits of existing websites keep surfacing the same patterns:

Problem area	Typical issue	Effort to fix
Contrast	Light grey text on white, unchecked brand colours	Low – adjust colour values
Forms	Placeholders instead of labels, errors shown only by colour	Medium – markup and validation
Keyboard	Menus and modals only operable by mouse	Medium – focus management
Images	Missing or meaningless alt text	Low, but an ongoing editorial task
Structure	Heading chaos, div soup instead of semantics	High – up to a rebuild, depending on the theme
PDFs	Scanned documents without a text layer	Considerable, depending on volume

The good news: this order is also a sensible prioritisation. Contrast, alt text and form labels deliver immediately noticeable improvements for real users – long before the last PDF is accessible.

Why overlays are not a solution

The market for “accessibility via script tag” is booming: drop in a widget, tick the box, done? Unfortunately not. Overlays place a control panel on top of the page (font size, contrast mode) but don’t repair the HTML underneath. An unlabelled button stays unlabelled for the screen reader – no matter which widget floats above it. The accessibility community considers overlays insufficient and sometimes an additional barrier, because they can collide with assistive technologies.

Real accessibility happens where the page is made: in the markup, the styling, the behaviour of the components.

Sanctions: what non-compliance risks

Enforcement lies with national market surveillance authorities. Violations can lead to orders up to prohibition of the service and – in Germany – fines of up to 100,000 €. On top of that sits competition law: warning letters from competitors or consumer associations. Transitional rules exist for legacy contracts – their interpretation is exactly the kind of detail question that belongs with a lawyer.

Realistically, the warning-letter and reputation risk is the more immediate lever for most shops than the authority. And independent of the law: roughly one in ten people has a disability, plus age-related vision loss, motor impairments and situational barriers (sunlight, one-handed use). Accessibility simply increases the number of people who can buy from you.

Side effect: accessibility feeds SEO

Much of what WCAG demands, Google demands too: semantic structure, alt text, clear heading hierarchy, fast and robust pages. Accessible websites are easier to read for search engines and AI search systems alike – the investment pays twice.

Free tools for a first self-check

You can find out roughly where your site stands in half an hour – these tools are free and require no sign-up:

• WAVE (WebAIM): The classic quick check. Enter a URL or use the browser extension – WAVE marks errors, contrast issues and structural flaws directly on the page. Ideal for a first overview.
• Silktide Accessibility Checker: Free browser extension that adds simulations to the error checking – for instance how your page appears with low vision, colour blindness or via screen reader. Great for building understanding in a team.
• axe DevTools (Deque): Browser extension built on the open-source axe-core engine that also powers many other tools. Precise findings with concrete code hints – the developer’s instrument.
• Lighthouse: Built into Chrome (DevTools → Lighthouse). The accessibility score is coarse, but a usable starting point with zero installation.
• WebAIM Contrast Checker: Checks two colour values against the WCAG thresholds – the tool for the conversation with design.
• Screen readers for self-testing: VoiceOver is preinstalled on every Mac (Cmd+F5), NVDA is free for Windows. Ten minutes operating your own site with keyboard and screen reader only teaches more than any report.

Important context: automated tools only find a fraction of WCAG violations – common estimates range from a third to half. A green score is a good sign, not proof of conformity. The tools tell you that alt text is missing – not whether the existing text makes sense.

A pragmatic approach: audit, priorities, routine

This is how we approach the topic – and how you can structure it without us:

1. Assessment. Automated checks with the tools above find the machine-readable problems; a manual pass with keyboard and screen reader finds the rest. Automation alone isn’t enough – it detects missing alt text, but not meaningless alt text.
2. Prioritise by impact. Blockers first (inoperable forms, unreadable contrast), then structure, then polish.
3. Anchor it in the foundation. On new builds and relaunches, accessibility belongs in the base – on our projects we test it automatically in CI so it doesn’t silently break with the next change.
4. Treat it as an ongoing task. Every new piece of content can introduce new barriers. Regular checks integrate well into ongoing maintenance.

If you want to know where your site stands: a structured audit delivers the assessment with prioritised recommendations – after that you’ll know whether it’s about colour values or a rebuild. And an upcoming relaunch is the best moment to get the topic right from the start.