Power Your Software Testing with AI Agents and Cloud
The Native AI-Agentic Cloud Platform to Supercharge Quality Engineering. Test Intelligently and Ship Faster.
- TestMu AI (Formerly LambdaTest)
- /
- Blog
- /
- How to Test for European Accessibility Act Compliance
How to Test for European Accessibility Act Compliance
How to test a website or app for European Accessibility Act compliance: EN 301 549 and WCAG 2.2 AA checks, tools, and a real e-commerce checkout audit.
Last Updated on:
To test for European Accessibility Act compliance, test each in-scope website, app, and document against the harmonised standard EN 301 549, which for web content means the WCAG 2.2 Level AA success criteria. Combine an automated scan with keyboard, screen reader, zoom, and reflow checks by a person, then publish the accessibility information the Act requires.
I have a simple rule in my own accessibility testing work: the moment a product will reach customers or internal staff, it gets an accessibility check. For products sold in the EU, the Act turns that habit into a legal duty, and this guide covers how to test for it. For who must comply and the legal requirements, see the companion guide to European Accessibility Act compliance.
TL;DR
- European Accessibility Act testing checks websites, apps, and documents against EN 301 549, the harmonised standard used to presume conformity with the Act.
- EN 301 549 V4.1.1, published in September 2026, references WCAG 2.2, so web testing for the Act means checking WCAG 2.2 Level AA success criteria.
- The European Accessibility Act has applied since 28 June 2025, and microenterprises providing services are exempt from its accessibility requirements.
- Automated scanners catch rule-based failures such as low contrast and missing labels, but W3C states that tools cannot determine accessibility on their own.
- WCAG 2.2 added criteria that older audits miss, including a 24 by 24 CSS pixel minimum target size and accessible authentication.
- Service providers under the Act must publish information explaining how their services meet the accessibility requirements, so test results feed that statement.
What Does EAA Testing Check?
The European Accessibility Act, Directive (EU) 2019/882, sets accessibility requirements for products and services such as e-commerce, banking services, e-books, electronic communications, and self-service terminals. The Directive does not list technical tests itself. In practice, conformity is shown against the harmonised European standard EN 301 549, which ETSI, CEN, and CENELEC maintain.
The current version, EN 301 549 V4.1.1, is dated September 2026 and references the WCAG 2.2 Recommendation. Its clauses map to what you test:
| EN 301 549 clause | Covers | What you test against |
|---|---|---|
| Clause 9: Web | Websites and web apps | WCAG 2.2 Level A and AA success criteria |
| Clause 10: Non-web documents | PDFs, office documents, e-books | Equivalent document requirements based on WCAG |
| Clause 11: Non-web software | Native mobile and desktop apps | Software requirements based on WCAG, plus platform accessibility services |
Because older audits were run against EN 301 549 V3.2.1, which was based on WCAG 2.1, a report from before this update can miss the newer WCAG 2.2 criteria described below.
Who Needs to Test for the EAA?
The Act has applied since 28 June 2025. Under Article 4(5), microenterprises providing services, defined in Article 3 as enterprises with fewer than 10 persons and an annual turnover or balance sheet total not exceeding EUR 2 million, are exempt from the accessibility requirements. Article 32 allows a transitional period ending on 28 June 2030 for services that use products already in use before 28 June 2025. Everyone else providing in-scope products or services in the EU needs test evidence.
How to Test a Website for EAA Compliance
- Define the scope - List the in-scope services and the user journeys that deliver them, such as browsing, sign-in, cart, checkout, payment, and account management. Test complete journeys, not only the home page.
- Run an automated scan - Scan every page in those journeys with WCAG 2.2 A and AA rules, for example with axe-core. This catches contrast failures, missing form labels, empty links, and missing alternative text quickly.
- Test with the keyboard only - Tab through each journey. Every control must be reachable and operable, focus must be visible, and focus must not be hidden behind sticky headers or banners.
- Test with screen readers - Use NVDA or JAWS on Windows, VoiceOver on macOS and iOS, and TalkBack on Android. Check that names, roles, states, and error messages are announced.
- Check zoom and reflow - Zoom to 400% or use a 320 CSS pixel wide viewport. Content should reflow into one column without horizontal scrolling.
- Check the WCAG 2.2 additions - Test target sizes, dragging alternatives, help placement, redundant entry, and authentication, which scanners cover only partly.
- Record results and fixes - Log each failure against its WCAG success criterion and EN 301 549 clause, then retest after fixes. These results support the information service providers must publish.
WCAG 2.2 Criteria to Add to Your Test Plan
According to W3C's summary of what is new in WCAG 2.2, version 2.2 adds 9 success criteria and removes 4.1.1 Parsing as obsolete. The six at Level A and AA are the ones an EAA test plan must cover:
| Success criterion | Level | How to test |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | Tab through the page with sticky headers, cookie banners, and chat widgets open; the focused control must not be fully hidden |
| 2.5.7 Dragging Movements | AA | Every drag action, such as a slider, must also work with a single click or tap |
| 2.5.8 Target Size (Minimum) | AA | Controls must be at least 24 by 24 CSS pixels, or have enough spacing around them |
| 3.2.6 Consistent Help | A | Help links or contact options appear in the same relative place on every page |
| 3.3.7 Redundant Entry | A | Information already entered in a process, such as an address, is filled in or selectable, not typed again |
| 3.3.8 Accessible Authentication (Minimum) | AA | Sign-in does not rely on a memory or transcription test unless an alternative, such as password paste or a password manager, works |
Austin Siewert
Co-Founder, Steadfast Systems
Discovered @TestMu AI yesterday. Best browser testing tool I've found for my use case. Great pricing model for the limited testing I do 👏
2M+ Devs and QAs rely on TestMu AI
Deliver immersive digital experiences with Next-Generation Mobile Apps and Cross Browser Testing Cloud
Example: WCAG 2.2 AA Audit of an E-Commerce Checkout
E-commerce is one of the services the Act covers, so I ran steps 2, 5, and part of 6 on the cart and checkout pages of the TestMu AI ecommerce playground, in Chrome 154 on Windows 11 on the TestMu AI cloud, with axe-core 4.13.0 set to WCAG 2.2 A and AA rules:
| Check | Cart page | Checkout page |
|---|---|---|
| Color contrast failures (1.4.3) | 7 elements | 11 elements |
| Form field without a label (4.1.2), critical | 1 | 1 |
| Links without an accessible name (2.4.4, 4.1.2) | 2 | 2 |
| Controls smaller than 24 by 24 CSS pixels (2.5.8 candidates) | 5 | 15 |
| Reflow at 320 CSS pixels (1.4.10) | No horizontal scroll | No horizontal scroll |
The checkout path fails WCAG 2.2 AA even though the pages reflow correctly on a small screen, so passing one check says little about the rest. The 24-pixel count is a list of candidates, not failures: target size 2.5.8 has a spacing exception, so a person has to check each small control before logging it. Keyboard, screen reader, and authentication checks still need a manual pass on top of this scan, as explained in why accessibility testing is important.
Conclusion
Scope your in-scope journeys, scan them with WCAG 2.2 AA rules, add keyboard, screen reader, and reflow checks, and log every failure against its WCAG success criterion and EN 301 549 clause so the results can support your published accessibility information. TestMu AI Accessibility Testing runs those scans in the browser with Accessibility DevTools, in CI/CD pipelines, and on a recurring schedule, and the accessibility automation documentation covers adding scans to an existing test suite.
Note: AI assistance was used in researching and updating this article. Laveena Ramchandani wrote the original article from experience leading accessibility work in test teams. Legal facts in this update were checked against the text of Directive (EU) 2019/882 on EUR-Lex, and standards facts against ETSI EN 301 549 V4.1.1 and W3C, following our editorial process and AI use policy.
Author
Laveena Ramchandani
Blogs: 4
Laveena Ramchandani is a passionate Test Manager who has been testing for nearly 10 years and is always seeking to learn and share. She is a community leader for data science testing and testing in general. Her entry on the digital platform has enhanced many individuals to learn a new area within testing. Laveena was a finalist for The Digital Star 2022 at the everywoman in Technology awards. She has also been on various podcasts, international speaker and blogs trains new testers.
Reviewer
Rahul Mishra
Reviewer
Rahul Mishra is a Lead Member of Technical Staff at TestMu AI (formerly LambdaTest), leading frontend engineering and accessibility testing across the quality engineering platform. He mentors frontend engineers, runs code reviews and sprint planning, optimizes React.js rendering performance, and makes product features accessible to users with disabilities through WCAG and ADA-compliant accessibility audits. He brings 10+ years of experience across React.js, VueJS, TypeScript, Swift, Objective-C, and AWS, with earlier work as a Technical Lead at VectoScalar Technologies. Rahul holds a B.E. in Information Technology.
EAA Testing FAQs
Did you find this page helpful?
More Related Blogs
TestMu AI forEnterprise
Get access to solutions built on Enterprise
grade security, privacy, & compliance
- Advanced access controls
- Advanced data retention rules
- Advanced Local Testing
- Premium Support options
- Early access to beta features
- Private Slack Channel
- Unlimited Manual Accessibility DevTools Tests