What You Need to Know About the European Accessibility Act (EAA)

Yeah, it's really sunny here in Hamburg. Usually it's overcast with a bit of rain, but lately the weather has been very pleasant.

We're about to experience 25-degree heat at the end of April here in London, which is very odd. To our audience — we are live, so please drop a message in the chat, say hello, let us know the chat is working. Björn, it'd be great for you to introduce yourself. What does an accessibility consultant do?

I'm Björn, I work with Tracking. I started there 5 years ago in conversion optimization, which is still my main area. About 3 years ago I came across the European Accessibility Act and it immediately clicked — back when I was young I did civil service working with people with disabilities, and I'd always had a dream of using computer science to help people with disabilities. I'd lost track of that somehow when I got into conversion optimization. When I caught wind of the EAA, I thought this was going to be big for e-commerce, so I dived into the web accessibility guidelines and grew with the topic. Last year was particularly busy with clients, and I'm happy to share what I've learned.

You've been passionate about this from the start, and now it's becoming a real intersection of conversions and accessibility. Can you tell us about the size of the prize? The internet is roughly 30 years old, and lots of users have grown up with it — there are now people in their 70s using the internet, eyesight is genuinely decreasing for the average user, and phones are getting smaller. What is the genuine business case for meeting EAA requirements beyond the legal obligation?

It's a kind of paradigm change. Accessibility isn't only good for people with disabilities — it helps everyone. Think about checking an Uber in bright sunlight when contrast is low, or the WhatsApp feature that transcribes voice messages so you can read them while commuting. These features have their roots in accessibility but are now universally useful. Font sizes and contrast are issues we encounter today, and will encounter more as we all age and become more reliant on mobile devices. Accessibility improves the overall user experience.

From our research across various sources, somewhere between 1% and 8% of internet users have visual impairments. Even at the conservative end, perfecting the internet for visually impaired users could deliver a 1% lift in conversions or revenue — and that's before we even talk about broader usability improvements.

Let's talk about the standards underpinning the EAA. The W3C — the World Wide Web Consortium — is the organization that defines internet standards, from HTML to how browsers read code. One of those standards is WCAG. Björn, can you give us a background on what WCAG means, why there are different versions, and what the different levels include?

WCAG — the Web Content Accessibility Guidelines — is essentially a compendium for making websites and web applications accessible. There are three levels of complexity. Level A is the baseline. Level AA is the intermediate level. Level AAA is the highest and most helpful for people with severe disabilities. On the legal side, you should have at least Level A and some Level AA criteria — though the law isn't very specific about this. The law also points to the European industry standard norm EN 301 549, which in turn references WCAG AA. So if you meet WCAG AA, you're on the safe side. That said, from the German government's perspective, there are indications that not every AA criterion will be strictly required — but that's not yet written in stone, and we're waiting for further guidance.

We've got a question from Mark in the chat: how fast do you think authorities will start to enforce this compared to how they enforced GDPR?

I don't think enforcement will start right from July. The law also says that pages that already existed before the deadline don't immediately need to comply — only new pages or updated ones may be obligated. Supervisory authorities want genuine improvement, not just box-ticking from day one. Our expectation is that from the beginning of next year, they'll start contacting companies, pointing out specific issues, giving them time to correct, and only fining if there's no response. A soft start to enforcement, essentially.

Is it true that for the next 2 years, existing websites and digital properties don't need to meet requirements, but new apps and new websites do?

That's where the law is genuinely unclear. In Germany, we're already hearing that a CMS update might be considered a "new page" and therefore fall in scope. New content published after June — a new news story, for example — would need to be accessible, while existing pages wouldn't. The gray area is what counts as an update versus existing content, and the supervising authority may clarify that in future.

How have your clients reacted to the deadline coming up?

There's been a real shift. Early last year, a lot of clients thought it would be straightforward — a step-by-step process their development and design teams could handle. By the end of last year, many were realizing this isn't something you just flip a switch on. It has moved from a low priority to a high priority, and we're now seeing organizations assign dedicated project managers to accessibility because of how complex it is depending on your website.

Where are organizations putting this work? Accessibility has UX implications, SEO implications, and it's really an organization-wide change. Which team is owning it?

Accessibility touches every team — design, development, content, product owners. What you really need is a technical project manager who is fluent across all of those areas, including marketing and SEO. It's essentially a new role — something like an accessibility manager — that the industry is only now beginning to define and hire for.

I've been thinking that maybe no one person should specialize, and instead everyone needs to develop some level of awareness — just as data privacy and accessibility both require cultural shifts rather than single-team ownership. The risk is that organizations end up needing everyone to absorb multiple cultural shifts simultaneously.

Which elements of the change are causing the most stress for your clients?

The deadline itself isn't the biggest stressor — it's the complexity of interpreting the WCAG guidelines. Take color usage as an example. The WCAG says you shouldn't use color as the sole means of conveying information. That sounds simple, but consider a form error displayed only in red. Someone with color blindness just sees text — they can't tell it's an error. The fix sounds straightforward: add an underline, an exclamation icon, or a popup. But identifying every instance of this on your site and deciding on the right fix takes real judgment, and there are multiple valid approaches. The complexity compounds when you factor in how many teams are involved. Even something like alt text for images now requires the photographer to write descriptions, which then need to be stored in a database the CMS can access. It's that kind of organizational chain that catches clients off guard.

So for a fashion brand launching a new seasonal catalog, every product photo would now need alt text for all future releases?

At minimum, yes — alt text on every image. Alternatively, if there's a caption beneath the image that fully describes the product, you can use ARIA attributes to link the caption to the image as an accessible description.

Are there industries you've seen that would be more affected or less affected by the EAA?

Industries with high product variety — large e-commerce catalogs, electronics retailers with complex specification tables, car manufacturers with configurators and heavy video content — these are the ones struggling most. The more complex your information hierarchy, the harder compliance becomes. Conversely, news and publishing sites that are primarily text-based have an easier time — if the article text already explains the story, a decorative feature image can often be marked as such and skipped by assistive technology.

So interactive product configurators — like choosing car options — would be particularly difficult to make accessible?

Yes, because those are transaction-completing journeys, which is exactly what the EAA is designed to protect — ensuring that people with disabilities can complete a purchase or contract just as easily as anyone else.

What's one myth or misconception you'd like to put to rest?

The biggest one is that accessibility overlay tools will make you compliant. These are widgets you add to your site that give users options to increase contrast, adjust fonts, switch on keyboard navigation, and so on. They sound helpful, but the German supervising authority has already stated they won't satisfy compliance requirements. The core problem is that if your underlying page isn't accessible, the overlay can't fix it. A user who relies on a screen reader or braille reader has to first navigate to the overlay button to activate it — which defeats the purpose entirely. These tools also rely on automatic detection, and they can conflict with accessibility settings users already have configured on their own devices. The overlay is not a substitute for building accessibility into the page itself. There is one legitimate use case: if your page is already fully accessible, an overlay can be a useful add-on for features like easy language for users with cognitive disabilities. But as a standalone solution? No.

So the naive assumption — subscribe to a tool, paste some JavaScript, and you're done — doesn't hold up.

Correct.

For someone who hasn't started yet and is responsible for a website's digital experience — where should they begin today?

Start small. Don't try to fix the entire site at once. Pick your homepage or your most important landing page, open up WCAG criterion 1.1.1, and ask: is this page compliant? Write down why it isn't, then bring your team together to discuss what you've found and how to fix it — from the SEO angle, the design angle, the development angle. After the first fix, the second becomes easier. You start to recognize patterns, build workflows, and accessibility becomes second nature for future releases. The most important thing is just to get started and not be paralyzed by the scale of the guidelines.

This is clearly an organization-wide shift that needs to become an ongoing process. Are there any quick wins that can help organizational leaders see tangible benefits early on — improvements in SEO or revenue — so they're willing to stay the course?

Navigation is the best place to start, because it's a module that appears across your entire site and has a direct impact on user experience. A common issue is hover menus that auto-close when you move your cursor away — WCAG says they should stay open until the user explicitly closes them, because some users need to move to a different screen or adjust settings before continuing. Simplifying navigation structure also helps users with cognitive disabilities, but frankly it helps everyone — if you've ever tried to book a hotel after a 14-hour flight, a complicated navigation feels genuinely impossible. These are changes that visibly improve experience and metrics.

We have a question from Maureen: are there any privacy concerns that need to be considered? For example, does a cookie consent banner need to load before your accessibility setup, or vice versa? Have you seen conflicting interactions between privacy technologies and accessibility?

The issue actually runs in the opposite direction — it's not that accessibility breaks privacy tools, it's that privacy tools are often not accessible. Cookie banners frequently have keyboard navigation issues: a user tabbing through the page can't navigate onto the banner itself because it's positioned at the bottom of the HTML, even though it appears visually on top. So the screen reader can read the page content behind the banner before the user has consented. The relationship between the two is something organizations need to be aware of, but the accessibility problem is typically in the banner, not the other way around.

Last question: for analytics teams looking to measure the impact of accessibility improvements — how would you identify visually impaired users in something like Google Analytics or Adobe Analytics so you could track conversion uplifts?

It's not possible to directly track users who rely on assistive technology. If a user increases their browser font size, for example, that information isn't passed to your analytics tool. The best approach is A/B testing — implement an accessibility improvement and look for a correlated uplift in your existing metrics. You won't know exactly which users benefited, but you'll see the aggregate effect.

Björn, thank you very much — it's been an absolute pleasure. For anyone who wants to reach out to Björn, you can email him at bjorn@tracking.com or find him on LinkedIn by searching Björn Buhay. Thank you to our audience as well for joining. We hope to see you on the next episode very soon.