The EU's New Accessibility Law, Explained for Small Devs

Since June 2025, there’s an EU law that says websites and digital services have to be usable by people with disabilities. Screen readers need to work. Keyboard navigation needs to work. Text needs to be readable. The official name is the European Accessibility Act, or EAA.

This should already be the default. Around 90 million people in the EU live with some form of disability - about one in four adults (source). That’s a real chunk of users who hit a wall when a site is built without them in mind. The law just makes the obvious thing mandatory.

Here’s how it works and what it actually asks for.

Who has to comply

The EAA covers consumer-facing digital services in the EU - e-commerce sites, banking apps, transport ticketing, telecom, e-books, SaaS products. If you serve EU customers, it applies regardless of where your company is based.

There’s an exemption for very small businesses, called the “microenterprise exemption.” Fewer than 10 employees AND less than €2 million annual turnover, and the EAA’s service rules don’t apply to you. Most solo founders fit into this. I do… unfortunately 🥲.

The exemption is narrower than it sounds, though. It only covers services, not products - so if you sell something physical the EAA regulates, like a payment terminal, the product rules still apply. And it’s tied to this specific law, not to accessibility in general. Other EU and national laws cover public sector sites and certain industries. The moment you grow past either threshold, the exemption is gone and you’re expected to comply.

What “accessible” actually means

The law points to a technical standard called WCAG 2.1 AA. The full thing is detailed, but for most websites and apps, the core of it comes down to:

Semantic HTML. Use the right tags for the right things. A button is a <button>, not a <div> with an onClick. This is what lets screen readers announce “button” instead of “generic container.”
Form labels. Every input has a proper <label> tied to it. So a screen reader user knows what they’re typing into.
Keyboard navigation. You can tab through the whole app and use it without a mouse. The focus indicator is visible.
Color contrast. Text is dark enough against its background to read. There are tools that check this in seconds.
Meaningful alt text. Images that convey information have alt text describing what they show. Decorative images have empty alt text so screen readers skip them.
No keyboard traps. A user navigating with the keyboard can always tab back out of a component.

That’s most of the work. Done from the start, it’s a small tax on each component you build. Bolted on at year three, it’s a rewrite.

I audited my own site

Writing this post made me wonder about my own blog. I iterate on this site constantly. I must have forgotten about accessibility somewhere along the way.

So I had an AI go through it with me. (I’ve been letting Claude Code into my projects more lately - this felt like a good use of it.) I pasted the rendered HTML and asked it to check the basics.

The good news: most of the bones are already in place. The not-so-good news: I found stuff anyway.

The newsletter email input has no label.
An empty <h2> left over from a layout change. Screen readers announce a heading and then… nothing.
A “Freelance” experience card linked to href="#", which jumps the page to the top when activated.
Some text using opacity tricks (text/40, text/60) that probably fails contrast checks.
No skip link, so keyboard users have to tab through the whole header on every page.

None of these are dealbreakers. All of them are 5-minute fixes. Of course, 5 minutes times five things is the kind of small task that sits in a backlog for months if I don’t ticket it.