Accessibility testing is the process of checking whether people with disabilities can use your digital product. Not a compliance checkbox. Not a design preference. It is a structured way to find out whether your app, website, or service works for people who use screen readers (software that reads the screen aloud), voice controls, switch devices (hardware that replaces a touchscreen), or who have visual, hearing, cognitive, or motor impairments.
The reason this matters now: the European Accessibility Act (EAA) came into force on 28 June 2025. If you operate a consumer-facing digital service in the EU with more than 10 employees or more than €2 million in annual turnover, accessibility testing is no longer optional. It is a legal requirement under EN 301 549, the EU's harmonised standard for digital accessibility.
This post covers what accessibility testing actually involves, what standard you are testing against, the difference between automated and manual testing, and how to start without hiring a consultancy.
What Does Accessibility Testing Actually Check?
Accessibility testing checks whether your digital product works for four groups of users. These are not edge cases. In the EU alone, Eurostat estimates that 87 million people have some form of disability.
People who cannot see the screen. Screen reader users. Testing checks whether a blind user can navigate your app, understand what is on each screen, and complete key flows (sign up, purchase, find information) using only VoiceOver on iOS or TalkBack on Android. Can they reach every button? Does the app announce what each element does? Can they tell where they are in a multi-step form?
People who cannot hear audio. Deaf and hard-of-hearing users. Testing checks whether videos have captions, whether audio cues are doubled as visual cues, and whether a deaf user can complete the same flows without missing information. If your app plays a sound to confirm a payment, does it also show a visual confirmation? If customer support is voice-only, is there a text alternative?
People who cannot use a touchscreen precisely. Motor-impaired users, switch device users, and people with temporary injuries (a broken wrist, for example). Testing checks whether touch targets are large enough for users with limited dexterity, whether the app can be navigated with a keyboard or switch device, and whether there are time limits that lock out slower users.
People who find complex interfaces hard to process. Users with cognitive and learning disabilities. Testing checks whether the language is clear, instructions are explicit, and the interface behaves consistently from screen to screen.
These four groups map to the four POUR principles in WCAG 2.1: Perceivable, Operable, Understandable, Robust. WCAG (Web Content Accessibility Guidelines) is the W3C's global accessibility standard(opens in new tab). In the EU, the controlling standard is EN 301 549(opens in new tab), which incorporates WCAG 2.1 AA for web and mobile content and adds requirements specific to mobile apps, software, and hardware. When someone says "accessibility testing" in an EU context, they mean testing against EN 301 549.
Why Accessibility Testing Is Now a Legal Requirement
The EAA (Directive (EU) 2019/882(opens in new tab)) is not a recommendation. It is binding EU law, transposed into national legislation across all 27 member states. It applies to e-commerce, banking, transport, telecom, e-books, and other consumer-facing digital services.
The standard you test against is EN 301 549. It sets the technical requirements. Each requirement maps to a specific test: does this screen have text alternatives for images? Can this button be reached by keyboard navigation? Is this video captioned?
Penalties vary by member state. Italy's transposition allows fines from €5,000 per violation. Spain's framework reaches €1,000,000 for very serious infringements. A full country-by-country breakdown is in our EAA fines guide.
Enforcement is live. France saw the first EAA-related court case in May 2026 (Auchan, Tribunal judiciaire de Lille), dismissed at first instance on a disputed domestic threshold but appealed by disability associations on 7 May 2026. Sweden's PTS has opened 39 investigations(opens in new tab) into e-commerce services. Germany's market surveillance authority for accessibility under the Barrierefreiheitsstärkungsgesetz (BFSG), the MLBF, has been operational since September 2025. No company has been fined under any EAA transposition yet, but the regulatory machinery is built and active.
The practical point: if a regulator or a disability association investigates your company, you need an audit trail showing what you tested, when you tested it, and what you found. Accessibility testing produces that trail. Without it, you have no evidence of compliance, regardless of how accessible your product actually is.
Automated vs Manual Accessibility Testing: What Each Catches
This is the section most existing guides get wrong. They present automated and manual testing as alternatives. They are not. They are two halves of the same process, and skipping either one leaves gaps that regulators and users will find.
Automated accessibility testing
Automated tools scan your product against a subset of EN 301 549 and WCAG rules. On the web, tools like axe, Lighthouse, WAVE, and pa11y run these scans. On mobile, Android's Accessibility Scanner and Xcode's Accessibility Inspector cover the basics.
What automated testing catches: missing alt text, insufficient colour contrast, missing form labels, broken heading hierarchy, missing language attributes, touch targets below the minimum size.
What automated testing misses: whether the alt text is meaningful, whether the screen reader navigation order makes sense, whether a complex interaction (an accordion, a carousel, a modal dialog) is operable, whether video captions are accurate, whether the product is usable in practice.
Automated tools catch roughly 30–40% of real-world accessibility issues. The remaining 60–70% require a human using your product with assistive technology. Any testing approach that skips manual testing is incomplete.
The 30–40% figure is widely cited across accessibility research, including findings from the UK Government Digital Service and Deque Systems. Automated tools are good at pattern-matching code against rules. They cannot judge whether a screen reader experience is coherent, whether instructions make sense, or whether a user can complete a task.
Manual accessibility testing
Manual testing means a person uses your product with assistive technology: a screen reader, a keyboard, a switch device. They attempt the core user journeys and record what works and what breaks.
This is where the critical issues surface. The checkout flow that traps keyboard users in a loop. The modal that a screen reader cannot dismiss. The form validation that only uses colour to indicate errors, invisible to a colour-blind user. The onboarding flow that requires a precise swipe gesture with no alternative for users who cannot perform it. These are the failures that generate complaints, regulatory attention, and real harm to users.
Manual testing does not require an accessibility specialist. It requires someone willing to turn on VoiceOver or TalkBack, follow a test script, and record what happens. The screen reader does not care whether the tester has a disability. It reads the same code the same way. What matters is that someone tests the product with the technology that real users depend on, and records the results honestly.
For mobile apps, this is especially important. EN 301 549 Chapter 11 includes requirements that go beyond WCAG: platform accessibility service support, user preference inheritance, closed functionality handling. These cannot be tested by automated scanners. They require a human with a device.
The right approach
Both. Automated scanning catches the obvious, repeatable issues quickly. Manual testing catches the ones that matter most to real users and to regulators. A credible digital accessibility audit under EN 301 549 combines both. Neither alone is sufficient. If your current process is "we run a scan and fix the red items," you are covering less than half the standard.
How to Test a Mobile App for Accessibility
Most guides on accessibility testing stop at "use a scanning tool." This section covers what a mobile app accessibility test looks like in practice, step by step.
1. Define your surfaces. A surface is a screen or flow: home screen, login, checkout, search results, settings. Most apps have 15 to 30 surfaces that matter. You do not test every pixel. You test the screens real users touch. Start with the flows that handle money, personal data, or onboarding. Those are the screens regulators and users care about most.
2. Pick your standard. In the EU: EN 301 549, which references WCAG 2.1 AA for mobile content. Each requirement maps to a specific test. The standard tells you what to check on each surface. If you also serve US customers, Section 508 and ADA case law reference WCAG 2.1 AA as well. The technical requirements overlap significantly.
3. Run the automated scan. Use Accessibility Scanner on Android or the Accessibility Inspector in Xcode on iOS to catch the automated checks: contrast ratios, touch target size, missing labels. Fix the obvious failures first. This clears the noise so your manual testing can focus on the issues that require human judgement.
4. Run the manual audit. Turn on VoiceOver (iOS) or TalkBack (Android). Navigate each surface. Can you complete the core flow? Does every element announce its purpose? Can you move backward as well as forward? Record pass or fail per requirement, per surface. Record every result, even the passes. The audit trail is built from the full picture, not just the failures.
5. Log the failures. Each failure becomes a remediation ticket: what failed, which screen, which EN 301 549 requirement, severity, assigned owner, target fix date. This log is the foundation of your audit trail. Without it, the testing happened but the evidence did not.
6. Fix, re-test, declare. Fix the tickets. Re-test the affected surfaces. Update the audit record. When the work is done, generate your accessibility statement from the results. The statement is the legally binding artefact under the EAA. It declares your conformance status, lists known gaps, and gives users a way to report barriers.
This is the workflow AUDITSU structures for your team. The audit toolkit walks teams through steps 1 to 6 against EN 301 549, with no accessibility expertise required. Each surface, each requirement, each result recorded and tracked in one place.
Five Accessibility Testing Mistakes That Leave You Exposed
1. Relying on automated tools alone. They catch 30–40% of issues. The failures that generate complaints and regulatory attention sit in the 60–70% that automation misses. A scan report is not an audit.
2. Testing once and declaring done. Accessibility degrades with every release. New features introduce new screens. UI redesigns change navigation patterns. A statement generated from a 2024 audit does not cover a 2026 app. Testing needs to be continuous, not annual. Every significant release should trigger a re-test of affected surfaces.
3. Testing the website but not the app. The EAA covers both. Most enforcement activity so far has focused on web. Mobile is next. Sweden's PTS has signalled that app inspections are coming. EN 301 549 Chapter 11 sets requirements specific to mobile that go beyond WCAG.
4. Confusing an overlay with a test. Accessibility overlays (widgets that sit on top of your product) do not test anything. They do not produce an audit trail. They do not satisfy EN 301 549. Regulators and disability organisations have rejected them consistently. An overlay is not a substitute for accessibility testing.
5. Not keeping an audit trail. The EAA requires you to demonstrate compliance, not just achieve it. If you test but do not record the results, you have no evidence when asked. The audit trail, not the product itself, is the compliance artefact a regulator looks for. The six elements an EAA-credible audit grades against all depend on documented evidence.
Where to Start
Accessibility testing is not a one-off project and it is not something only specialists can do. It is a repeatable process your product and compliance team can run in-house with the right structure. The standard is public. The assistive technology is built into every phone. What most teams lack is not expertise. It is a workflow that connects the standard to the screens, tracks the findings, and produces the evidence a regulator recognises.
AUDITSU gives product and compliance teams that structure. The audit toolkit walks your team through EN 301 549 requirements screen by screen, logs every result, tracks remediation, and generates a jurisdiction-specific accessibility statement from the evidence. No accessibility expertise required. No code access needed. From £197 per month.