Accessibility audit and remediation

WCAG 2.2 AA audits and the fixes in your code, for teams under the European Accessibility Act or asked for a conformance report.

Price
Fixed price for the audit, then a quote for the fixes
Timeline
Audit first, then fixes in stages
Engagement
fixed-scope project

An audit of your web app against WCAG 2.2 AA with automated checks and manual testing (keyboard, screen readers, zoom and contrast), then the fixes in your code and the tests that keep them fixed: axe checks in CI and keyboard tests on the key journeys. This site runs axe with WCAG 2.2 AA and best-practice rules on every template in CI.

  1. 01

    An audit report mapped to WCAG 2.2 success criteria, ranked by impact on users

  2. 02

    Fixes in your codebase, reviewed with your team

  3. 03

    Automated axe checks and keyboard tests in CI

  4. 04

    A draft accessibility statement for your site

  5. 05

    Input for a conformance report (VPAT) where you need one

Who this is for

  • Products sold to consumers in the EU that fall under the European Accessibility Act
  • B2B software asked for an accessibility conformance report during procurement
  • Teams that fixed issues once and watched them come back

Who this is not for

  • A certificate without fixing anything
  • Overlay widgets that claim to fix accessibility automatically

What this service is

Accessibility audit and remediation is testing a web application against WCAG 2.2 level AA, with automated checks and manual testing by keyboard, screen reader, zoom and contrast, then fixing the issues in your code and adding the tests that keep them fixed. It is for products sold to consumers in the EU that may fall under the European Accessibility Act, B2B software asked for an accessibility conformance report during procurement, and teams that fixed issues once and watched them come back.

This site runs axe checks against WCAG 2.2 AA and best-practice rules on every template in CI.

Scope

The audit covers the journeys that matter most, sign-up, search, checkout, the core task of your product, rather than a sample of random pages, because an issue that stops someone completing a task matters more than ten cosmetic ones. The audit is fixed-price; the fixes are quoted after it, in stages, blockers first.

What is tested and fixed

Automated tools catch part of the problem: missing labels, contrast failures, invalid ARIA, missing alternative text. Manual testing catches the rest: whether every control works by keyboard alone with a visible focus, whether a screen reader announces things in a sensible order, whether content survives zoom and narrow screens, whether errors are explained, and whether motion can be reduced. I test with NVDA on Windows and VoiceOver on macOS and iOS.

Each finding is mapped to the WCAG 2.2 success criterion it fails and ranked by impact on users. Fixes go into your codebase, reviewed with your team, and the guard rails go into CI: axe checks on each template and keyboard tests on the key journeys, so regressions fail the build. The report also gives input for a conformance report (VPAT) and a draft accessibility statement.

The European standard for ICT accessibility, EN 301 549, reflects WCAG 2.1 in version 3.2.1 and is aligned with WCAG 2.2 in version 4.1.1, published in September 2026; an audit at WCAG 2.2 AA covers both.

What it is not

It is not a certificate without fixes, and it is not an overlay widget. Overlays don't change the underlying code, can get in the way of assistive technology, and don't make a site conform. It is also not legal advice about whether the Act applies to you.

How the engagement runs

  1. Audit

    Automated scans plus manual testing of the journeys that matter most.

  2. Fix the blockers first

    Issues that stop people completing a task come before cosmetic ones.

  3. Guard in CI

    Automated checks and keyboard tests so fixed issues stay fixed.

  4. Document

    A statement for your site and the evidence for procurement questionnaires.

Technologies I use for this

  • WCAG 2.2
  • EN 301 549
  • axe-core
  • Playwright
  • NVDA
  • VoiceOver
  • React
  • Next.js
  • Vue.js

How this works in your market

How this works in the European Union

For teams in the European Union, the European Accessibility Act has applied since 28 June 2025 to a list of consumer products and services that includes e-commerce, consumer banking, e-books and electronic communications, with an exemption for microenterprises providing services and transitional arrangements for some existing services. Whether and how it applies to your product is for your counsel to confirm; the audit gives them the technical facts.

How this works in South Korea

For teams in South Korea taking a product to Europe, accessibility is cheapest to build in the same pass as the product. I audit against WCAG 2.2 AA, which is the reference European buyers and procurement teams ask about, fix at the component level so every screen benefits, and leave the checks in CI for your team. Confirm the legal position in your target markets with your counsel.

Questions about Accessibility audit and remediation

Does the European Accessibility Act apply to us?

It has applied since 28 June 2025 to many consumer-facing products and services sold in the EU, e-commerce included, with an exemption for microenterprises providing services. Whether it covers your product is a legal question; I cover the engineering.

Can't we just install an overlay?

No. Overlays don't fix the underlying code, can get in the way of assistive technology, and don't make a site conform.

Do you test with screen readers?

Yes: NVDA on Windows and VoiceOver on macOS and iOS for the key journeys, alongside the automated checks.

WCAG 2.1 or 2.2?

2.2 AA. It includes everything in 2.1 AA, which version 3.2.1 of the European standard EN 301 549 references, and adds criteria such as visible focus not being hidden and accessible authentication; version 4.1.1 of the standard, published in September 2026, is aligned with WCAG 2.2.

How much can automated tools find?

A useful share, quickly and on every build, but not everything: whether a screen reader user can complete a checkout needs a person. The audit uses both.

Will you write our accessibility statement?

I draft it from the audit results, with known issues and plans listed honestly. Your team or counsel publishes it.

Related writing

Where this work happens