European Accessibility Act checklist and testing: a practical guide for product teams

What the European Accessibility Act requires

The European Accessibility Act (Directive (EU) 2019/882) requires certain products and services sold to consumers in the EU to be accessible to disabled people. EU countries have had to apply their national versions of it since 28 June 2025.

For a digital service, the provider must design and run it to the requirements in Annex I, publish how it meets them, and keep it compliant as the service or the standards change (Article 13). For companies that sell to EU consumers, and the teams that build their products, European Accessibility Act testing is therefore a release-by-release job, not a launch task.

Which products and services are in scope

The EAA covers a defined list of consumer products and services, not every website. Article 2 lists these services, when provided to consumers after 28 June 2025:

• E-commerce: services provided at a distance through websites and apps, at a consumer's request, to conclude a consumer contract: in practice, most online shops that sell to consumers.
• Consumer banking, such as consumer credit, payment services and payment accounts.
• E-books and their dedicated software.
• Passenger transport by air, bus, rail and water: websites, apps, e-tickets, real-time travel information and interactive self-service terminals. For urban, suburban and regional transport, only the terminals.
• Electronic communications, access to audiovisual media services, and answering calls to the emergency number 112.

Covered products include computers and operating systems, smartphones, e-readers and self-service terminals such as ATMs. Three details matter when you check scope:

• Consumers, not businesses. A purely business-to-business portal is not on the list.
• Location. A service provider is anyone who provides a service on the EU market or offers it to consumers in the EU, so a UK or US company selling to EU consumers may be in scope.
• Exclusions (Article 2(4)): pre-recorded media and office files published before 28 June 2025, unedited archives, navigational maps whose essential information is also given accessibly, and third-party content the business neither funds, develops nor controls.

Key dates and transitional periods

The key date is 28 June 2025, when EU countries had to start applying the rules. Some transitional periods run until 2030.

How these rules apply to a particular website or app is a legal question, and national laws differ, so do not assume a grace period without advice.

The microenterprise exemption

Microenterprises that provide services are exempt from the service accessibility requirements (Article 4(5)). A microenterprise has fewer than 10 employees and an annual turnover or balance sheet total of no more than €2 million (Article 3). The exemption is narrow:

• Services only. Microenterprises dealing in covered products must still comply, although they need not document a disproportionate-burden assessment (Article 14(4)).
• Everyone else must comply or justify. Any business can argue that a requirement would fundamentally alter its service or impose a disproportionate burden (Article 14). It must document the assessment, keep it for five years, inform the relevant authority and, for services, renew it at least every five years. Funding received to improve accessibility rules out the burden argument.

EN 301 549, WCAG and the EAA

The European Accessibility Act's website requirements are functional, not technical: websites and apps must be perceivable, operable, understandable and robust (Annex I, Section III), the four principles WCAG is built on. The directive never mentions WCAG. The detail comes from harmonised standards: a service that conforms to one cited in the Official Journal of the EU is presumed to meet the requirements it covers (Article 15).

For digital services, the relevant standard is EN 301 549, from ETSI, CEN and CENELEC. As of 26 September 2026, two versions matter:

• V3.2.1 (2021) was prepared for the Web Accessibility Directive for public-sector websites and apps. For web content it includes WCAG 2.1 Level AA unchanged, according to W3C WAI. The EU's AccessibleEU centre says it remains the current reference until the new version is cited.
• V4.1.1 (2026-09) was prepared under the Commission's standardisation request for the EAA. It aligns its web, document and software clauses with WCAG 2.2 and adds Annex ZB, which maps it to the EAA. Once it is cited in the Official Journal, meeting the clauses listed in its clause A.2 gives a presumption of conformity. It has not been cited yet.

The practical answer is to test to WCAG 2.2 Level AA. It keeps the WCAG 2.1 success criteria, apart from 4.1.1 Parsing, which W3C removed as obsolete, and adds nine more, so you meet today's reference and are ready for the next. Our guide to AI accessibility testing explains the new criteria.

The accessibility information services must publish

Service providers must publish information on how their service meets the accessibility requirements (Article 13(2) and Annex V). It is often called an EAA accessibility statement, although the directive does not use that term. It belongs in the general terms and conditions, or an equivalent document, and should include where applicable:

• a general description of the service in accessible formats;
• the explanations needed to understand how the service works;
• a description of how the service meets the relevant requirements of Annex I.

Providers must also show how their delivery process and monitoring keep the service compliant. The information must be public, in written and oral format, accessible, and kept while the service runs. Online shops must also pass on accessibility information about the products they sell when the manufacturer or other responsible business provides it.

A claim such as "we test every release against WCAG 2.2 AA" needs reports behind it.

How the EAA is enforced

Each EU country enforces its own law and must designate authorities that check services, follow up complaints and verify that problems are fixed (Article 23).

• Complaints and court action. Consumers, and organisations with a legitimate interest such as disability groups, can take action before courts or administrative bodies (Article 29).
• Penalties. They must be effective, proportionate and dissuasive, and reflect how serious the failure is and how many people are affected (Article 30). Amounts are set nationally.
• Duties when something is wrong. The provider must fix it, immediately inform the competent authorities (Article 13(4)) and provide evidence of conformity when asked (Article 13(5)).

Check the national law in each market you sell into. EUR-Lex lists the national transposition measures each country has reported.

A practical EAA testing process

Reliable European Accessibility Act testing combines three layers: an automated rules engine on every build, manual expert checks, and assistive technology, ideally with disabled people. W3C's WCAG-EM 2.0 methodology gives a sound structure.

1. Define the scope. List the key journeys: browse, search, product page, basket, checkout, payment, sign-in, account, help and contact, plus the mobile app if there is one.
2. Choose a representative sample. As WCAG-EM describes, explore the product, then sample page types, states and complete processes. Test the whole checkout, not just its first page.
3. Automate the rules. Engines such as axe-core catch missing names and labels, many contrast failures, invalid ARIA and structural errors on every build. Treat "needs review" results as work for a person, never as passes.
4. Check manually. Keyboard-only use, focus order and visibility, zoom and reflow, error messages, timeouts, and whether alt text and link text make sense.
5. Use assistive technology. Screen readers on desktop and mobile, voice control and magnification on the key journeys. WCAG-EM strongly recommends involving people with disabilities too.
6. Cover identification, security and payment. The directive names these for banking and e-commerce. Include embedded third-party widgets; the third-party exclusion is narrow.
7. Record evidence and re-test. Keep dated reports of what was tested, failed, fixed and not covered, and re-run the checks on every release.

What automated testing can and cannot catch

Automated tools find a meaningful share of accessibility issues, but far from all. How big a share depends on how you count.

• In a 2017 test by the UK Government Digital Service, 10 tools were run against a page with 143 deliberate barriers. Together they missed 42 (29%), and no single tool found more than 41%, even counting prompts for manual inspection.
• In a 2021 study, Deque, which makes axe-core, analysed more than 2,000 audits covering more than 13,000 pages and found its automated tests identified 57% of issues by volume. Some issue types occur far more often than others, so counting by volume gives a higher figure than counting WCAG success criteria.
• W3C's WCAG-EM 2.0 puts it plainly: most accessibility checks are not fully automatable.

A clean automated report is not proof of EAA conformity. Use automation for breadth on every build, and spend human time on meaning, context and complete journeys.

EAA checklist for product teams

Use this EAA compliance checklist for each product or service you offer to EU consumers:

• Confirm scope with a qualified adviser: consumer-facing, on the list, sold to EU consumers, not a microenterprise.
• Write the target into your requirements and definition of done: WCAG 2.2 Level AA, with EN 301 549 as the reference standard.
• Agree who owns what: design, build, content, third-party widgets, the accessibility information and fixes after launch.
• Build accessibility into the design system: contrast-safe colour tokens, visible focus states, adequate target sizes and accessible components.
• Run automated accessibility checks on every build, and block releases on serious failures.
• Test key journeys by keyboard and screen reader, including checkout, payment, sign-in and third-party components.
• Draft the Annex V accessibility information and publish it with your terms.
• Keep dated evidence for each release: what was tested, failed, fixed and not covered.
• Set up a route for accessibility complaints and a process to fix problems quickly.
• Re-test after every significant change, and when the standard is updated.

For the rest of your pre-launch list, see our website QA checklist. To record who approved each release, use the UAT sign-off template. To work through the WCAG 2.2 Level AA target itself, try our free WCAG 2.2 quick check, an in-browser checklist of all 55 Level A and AA criteria.

Where ShipperAG fits

ShipperAG is designed to make accessibility testing for the EAA practical on every release. It checks your preview or staging build in a real Chromium browser, confirms each finding before it is reported (see how it works), and the report lists verified items, issues, open questions and what was not covered.

It does not replace a manual audit, assistive technology testing or legal advice; it gives you an evidenced baseline, so human effort goes where it matters. ShipperAG is in a private pilot: meet the AI QA specialists behind it.

Sources, checked 26 September 2026: Directive (EU) 2019/882 on EUR-Lex (Articles 2, 3, 4, 13, 14, 15, 23, 29, 30, 31 and 32, Annexes I and V); EUR-Lex, national transposition measures; European Commission, European Accessibility Act; AccessibleEU, The European accessibility standard EN 301 549 has been updated (7 September 2026); ETSI, CEN and CENELEC, EN 301 549 V4.1.1 (2026-09); W3C WAI, EU policies, What's new in WCAG 2.2 and WCAG-EM 2.0 (W3C Group Note, 23 July 2026); GOV.UK Accessibility blog, What we found when we tested tools on the world's least-accessible webpage (24 February 2017); Deque, automated testing study (10 March 2021); axe-core on GitHub.