The European Accessibility Act: what it means for your website and app

For years, web accessibility was treated by many businesses as a nice-to-have. In the European Union that changed on 28 June 2025, when the European Accessibility Act (EAA) began to apply. It requires a range of products and services, including many websites and mobile apps, to be accessible to people with disabilities.

This article explains the essentials in plain language and gives you a practical checklist. It is general information, not legal advice; for decisions about your specific obligations, consult a qualified adviser in the relevant member state.

What the European Accessibility Act is

The EAA is an EU directive (Directive (EU) 2019/882). Each member state has transposed it into its own national law, so penalties and enforcement bodies vary by country, but the core requirements are harmonised across the EU. It applies to products and services placed on the market or provided to consumers after 28 June 2025.

Which services are covered

The EAA covers specific categories of consumer products and services. For digital teams, the most relevant are:

• E-commerce services: websites and apps through which consumers buy products or services.
• Consumer banking services, including online and mobile banking.
• Electronic communications services and access to audiovisual media services.
• Passenger transport services by air, bus, rail and water, including websites, apps, e-tickets and real-time travel information.
• E-books and dedicated reading software.

It can also apply to businesses based outside the EU if they provide covered services to consumers in the EU.

Transition periods

Service contracts agreed before 28 June 2025 can continue unchanged until they expire, for no longer than five years from that date. Self-service terminals such as ticket machines already in use may continue to be used until the end of their economically useful life, up to 20 years. New websites, apps and features launched now should be designed to comply.

The technical standard

The EAA itself describes accessibility requirements in general terms. In practice, compliance is assessed against the harmonised European standard EN 301 549, which incorporates the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA for web content and applies similar criteria to mobile apps and documents. WCAG 2.2, published in October 2023, adds further criteria and is a sensible target for new work.

WCAG is organised around four principles: content must be perceivable, operable, understandable and robust. Here is what that means day to day.

A practical checklist

Perceivable

• Meaningful images have descriptive alternative text; decorative images are hidden from screen readers.
• Text contrast is at least 4.5:1 against its background, or 3:1 for large text; icons and input borders that convey meaning reach 3:1.
• Video has captions; audio-only content has a transcript.
• Information is never conveyed by colour alone, for example form errors also use text or an icon.
• Content reflows at 320 CSS pixels wide and remains usable when text is enlarged to 200%.

Operable

• Everything can be done with a keyboard alone, in a logical order, with no keyboard traps.
• A clearly visible focus indicator shows where the keyboard focus is.
• Users can skip repeated navigation with a skip link.
• Nothing flashes more than three times per second.
• Time limits can be extended, and moving or auto-updating content can be paused.
• Touch targets are large enough to tap reliably.

Understandable

• The page language is declared, and headings describe the content that follows.
• Every form field has a visible label, and errors explain what went wrong and how to fix it.
• Navigation and components behave consistently across the site.
• Instructions do not rely only on shape, position or sound.

Robust

• Use real HTML elements: buttons for actions, links for navigation, proper headings and lists.
• Custom components such as menus, tabs and dialogs expose the right roles, names and states to assistive technologies.
• Status messages, such as “added to basket”, are announced to screen reader users.

How to test

Beyond the code

• Publish an accessibility statement explaining how your service meets the requirements, any known limitations and how users can contact you.
• Include accessibility in design reviews and your definition of done, so new features do not reintroduce problems.
• Train designers, developers and content editors; many issues come from content, such as images without descriptions or PDFs without structure.
• Check third-party components such as chat widgets, payment forms and cookie banners, since they are part of your service too.

Where to start

1. Confirm whether your services fall within the EAA’s scope and whether any exemption applies.
2. Run an audit of your key journeys: home page, search, product pages, sign-up, checkout and account pages.
3. Fix issues in order of impact, starting with anything that blocks a task entirely.
4. Build accessible patterns into your design system so fixes carry across the product.
5. Publish an accessibility statement and a contact route for feedback.
6. Re-test after every major release.

We design and build to WCAG 2.2 AA by default, and we can audit existing websites and apps against EN 301 549 and help you fix what we find. If you sell to customers in the EU, now is the right time to check.