Accessibility audit: WCAG 2.2 AA and the European Accessibility Act

An accessibility audit is a structured review of a website or app against an accessibility standard, usually WCAG 2.2 level AA, to find everything that stops disabled people from using it. Our audit combines automated scanning with manual testing by keyboard and screen reader. Then we fix what we find in your code, re-test it, and draft your accessibility statement.

The European Accessibility Act: what changed on 28 June 2025

The European Accessibility Act (EAA, Directive (EU) 2019/882) has applied since 28 June 2025. It requires many products and services sold to consumers in the EU to be accessible to people with disabilities. For digital services, the main ones are:

• E-commerce services: online shops and other websites and apps where consumers buy products or services
• Consumer banking services, including banking websites and apps
• E-books and the software used to read them
• Electronic communications services
• Passenger transport services by air, bus, rail and water: websites, apps, e-tickets and travel information

It applies to companies outside the EU that serve EU consumers, too. Microenterprises that provide services, meaning fewer than 10 employees and no more than €2 million in annual turnover or balance sheet total, are exempt. Some transition rules apply to existing contracts and products, but new and updated services are expected to comply now. Enforcement is handled by national authorities in each member state, which also set the penalties.

In practice, conformity for websites and apps is shown against EN 301 549, which incorporates the WCAG success criteria at level AA. Covered service providers must also publish information explaining how their service meets the accessibility requirements, usually as an accessibility statement.

In the US, the ADA is regularly applied to websites in court, with WCAG as the usual reference, so the same work protects you in both markets. This section is general information, not legal advice.

What goes wrong without an audit

• Checkout doesn’t work by keyboard. A custom dropdown or payment modal traps focus, and customers who don’t use a mouse can’t buy. Under the EAA, that is a compliance gap as well as lost revenue.
• The overlay widget. Someone installed an accessibility toolbar and assumed the problem was solved. The code underneath still has the same issues.
• A perfect automated score. The scanner reports zero errors, but the screen reader announces every icon button as “button”, and error messages never get read out.
• The procurement questionnaire. An enterprise or public-sector customer asks for your accessibility statement or conformance report, and you don’t have one.
• The broken component. One inaccessible component in your design system, a date picker for example, is used on forty pages, and every one of them inherits the problem.

How our WCAG audit works

1. Scoping. We agree a representative sample of pages, templates and flows, such as home, product listing, product page, cart, checkout, account and forms, following the W3C’s WCAG-EM methodology.
2. Automated scan. We run axe-core across the whole site to catch the issues machines detect reliably.
3. Manual testing. We test every page in the sample with only a keyboard and with screen readers (NVDA on Windows, VoiceOver on macOS and iOS). We also check zoom to 400% and reflow, colour contrast, forms and error messages, focus order and visibility, motion, and the WCAG 2.2 additions: focus not obscured, target size, dragging alternatives, accessible authentication, consistent help and redundant entry.
4. Reporting. Every issue is logged with its WCAG success criterion, severity, location, screenshot, steps to reproduce and a concrete fix.

We audit and fix

Most audits end with a report. Ours continues:

• Fixes in code. We fix issues as pull requests in your codebase (React, Vue, Svelte, Astro, plain HTML and others), or give your developers a step-by-step fix guide if you prefer to do it yourselves.
• Re-test. We re-test every fixed issue and give you an updated report.
• Accessibility statement. We draft a statement describing your conformance status, known limitations and a contact route for users, ready for your legal review.
• Regression checks (optional). We add automated accessibility checks to your CI with Playwright and axe-core, so new issues are caught before they ship. See our QA automation services.

What you do: give us access to the site (and a staging environment if fixes are in scope), review our pull requests, and confirm the statement with your legal contact. What we do: the audit, the fixes, the re-test and the statement draft.

What you get

• An audit report mapping every issue to a WCAG 2.2 success criterion, with severity, location, screenshots and a fix
• Fixes as pull requests, or a fix guide for your developers
• A re-test report confirming what is resolved
• A draft accessibility statement aligned with EAA requirements
• Optional: automated accessibility checks running in your CI

Who it’s for

A good fit:

• E-commerce, SaaS, fintech and travel companies serving EU consumers
• Teams that have to show EAA compliance and don’t know where they stand
• Companies selling to enterprise or public-sector customers who ask for accessibility documentation
• US companies that want to reduce ADA risk

Not a good fit:

• If you want a badge or certificate without fixing anything: no official certificate exists
• If you want an overlay installed: we’ll recommend removing it
• Native iOS or Android apps: this audit covers websites and web applications
• If you need legal advice on your obligations: we work alongside your lawyer, not instead of them