The European Accessibility Act for web teams: what applies, and an engineering checklist

The European Accessibility Act (Directive (EU) 2019/882) is the EU law that, since 28 June 2025, requires a defined set of consumer products and services, e-commerce and consumer banking among them, to be accessible to people with disabilities. For a web team, it means the website and app of a covered service must be "perceivable, operable, understandable and robust", in the Directive's own words, which in practice means meeting the European standard EN 301 549 and the WCAG success criteria it is built on.

I audit and fix web applications against WCAG 2.2 AA, and this site runs automated accessibility checks on every template in its build. This guide is what I tell teams who ask whether the Act touches them and what to change first. It is engineering guidance read from the primary texts, not legal advice: whether the Act applies to your business, and how your member state enforces it, is for you to confirm with your counsel.

What applies from June 2025?

Article 31 of the Directive required member states to adopt their national laws by 28 June 2022 and to apply them from 28 June 2025. Article 2(2) lists the services covered when they are provided to consumers after that date:

• electronic communications services;
• services providing access to audiovisual media services;
• parts of air, bus, rail and waterborne passenger transport services, including their websites, apps and electronic tickets;
• consumer banking services;
• e-books and dedicated software;
• e-commerce services.

E-commerce is the broad one for most web teams. The Directive defines it as services provided at a distance, through websites and mobile apps, at the individual request of a consumer, with a view to concluding a consumer contract. If a consumer in the EU can buy from you online, treat the service as in scope until your counsel tells you otherwise. The European Commission's overview of the Act lists the same families of products and services.

There are transitional arrangements, and they are narrower than people hope. Article 32 lets a service keep using products it lawfully used before 28 June 2025 until 28 June 2030, and lets service contracts agreed before 28 June 2025 run unchanged until they expire, for at most five years. Article 2(4) leaves some content out, such as pre-recorded audio and video and office documents published before 28 June 2025, and archives that are no longer updated. None of that covers the checkout you ship next quarter.

What does "accessible" mean for a website?

Annex I sets the requirements. For services, it asks that websites, "including the related online applications", and mobile apps are made accessible "in a consistent and adequate way by making them perceivable, operable, understandable and robust". For e-commerce it adds two things: the identification, security and payment functions delivered as part of the service must meet the same test, and accessibility information about the products sold must be passed on when the manufacturer provides it.

The Directive never names WCAG. Annex V lets a service provider rely, in full or in part, on harmonised standards whose references are published in the Official Journal. For the web, the European standard written for this is EN 301 549, and its web clauses are WCAG.

EN 301 549 and WCAG: which version?

This changed in September 2026, so it is worth being precise.

V4.1.1's foreword says the presumption of conformity with the Act begins once the standard is cited in the Official Journal under the Directive, so check its status there before you write "conforms with EN 301 549" in a contract. The engineering answer doesn't depend on that date: test against WCAG 2.2 Level AA. It covers WCAG 2.1 AA, which is what V3.2.1 asks, and it is what V4.1.1 aligns with.

Is a small company exempt?

Partly, and only for services. Article 4(5) says "Microenterprises providing services shall be exempt" from the accessibility requirements for services and the obligations that go with them. Article 3(23) defines a microenterprise as one that employs fewer than 10 persons and has an annual turnover, or an annual balance sheet total, not exceeding EUR 2 million.

Two cautions. First, the exemption is about size, not about how small your online shop feels; a ten-person team is already over the line. Second, Article 14 lets any operator argue that compliance would fundamentally alter its service or impose a disproportionate burden, but it must carry out and document that assessment against the criteria in Annex VI, keep the results for five years and hand them to the authority on request. It is not a blanket opt-out. Confirm with your counsel before relying on either.

What does a service provider have to publish?

Article 13 asks service providers to design and provide services that meet the requirements, to prepare the information described in Annex V, and to keep the service conforming as it changes. Annex V puts that information in your general terms and conditions or an equivalent document: a general description of the service in accessible formats, the explanations needed to understand how it operates, and a description of how it meets the requirements. It must be available in written and oral form, in a way people with disabilities can use, for as long as the service runs. When the service falls short, the provider fixes it and informs the competent national authorities.

How is it enforced?

Each member state enforces its own transposition. Germany is a useful example because its rules are public and specific. Its law, the BFSG, has applied since 28 June 2025, and a joint market surveillance office of the federal states, the MLBF, supervises it nationwide. Under section 37 of the BFSG, offering or providing a service that doesn't meet the requirements can be fined up to €100,000, and the other listed offences, such as failing to give required information, up to €10,000. Other member states have their own authorities and penalties; your counsel will know which ones apply to the countries you sell into.

The engineering checklist

This is the order I work in on a covered product.

1. List the journeys a consumer needs. Find a product, compare, sign up or sign in, buy, pay, manage the account, get help. Audit these end to end, not a random sample of pages; a barrier that stops someone completing a purchase matters more than ten cosmetic ones.
2. Test against WCAG 2.2 AA, by tool and by hand. Automated checks find missing labels, contrast failures and invalid ARIA. Manual testing finds the rest: every control usable by keyboard alone, focus visible and not hidden under a sticky header, a screen reader announcing things in a sensible order, text resized to 200 percent and content reflowed at a width of 320 CSS pixels without loss, motion that can be reduced.
3. Fix at the component level. One accessible button, input, dialog, menu and table, used everywhere, fixes a finding across the whole product. Put contrast into the design tokens so a new screen can't fail it by accident.
4. Make forms forgiving. Errors identified and described in text, labels that stay visible, information already entered offered again rather than retyped, and no puzzle or memory test at sign-in without an alternative. WCAG's own examples of what satisfies Accessible Authentication include letting password managers fill the field and allowing paste.
5. Test the payment and identity steps you didn't build. The Act names identification, security and payment. A third-party card form, a 3-D Secure challenge or an ID check inside your journey is part of your service to the consumer, so test it, report it to the vendor and keep a fallback.
6. Caption and transcribe new media. Pre-recorded video published before 28 June 2025 is excluded; what you publish now is not.
7. Put guard rails in CI. Automated checks on every template and keyboard tests on the key journeys, failing the build on a regression. This is the part that keeps an audit from going stale.
8. Publish the Annex V information in your terms or an equivalent page, written from the audit, so it describes the service you actually run.
9. Write down any exemption before you rely on it: your microenterprise status or your Article 14 assessment, with the reasoning and the date.
10. Keep conformity as a habit. Accessibility in the definition of done for each feature, a re-test when a journey changes, and a note of which version of EN 301 549 and WCAG you test against.

How I do this

The accessibility audit and remediation offer starts with a fixed-price audit of the journeys above against WCAG 2.2 AA, then fixes the findings in your code, blockers first, and adds the CI checks that keep them fixed; the report also feeds your Annex V information and any conformance report a buyer asks for. If you are building the product now, web platform development puts accessible components in from the first sprint, which is far cheaper than retrofitting them. The market page for the European Union covers the other rules I design for there, from the GDPR to the AI Act.