Accessibility Audit

An accessibility audit your developers can act on.

Find out where people using a keyboard, a screen reader or zoom get stuck in your product. We evaluate an agreed sample against WCAG 2.2, write findings your team can reproduce, fix what you commission and retest the result.

Scope your accessibility audit →

DIRECT ANSWER

An accessibility audit evaluates a defined sample of a product against WCAG 2.2 success criteria, combining automated checks with manual keyboard, screen-reader and zoom testing. This engagement delivers reproducible findings, prioritized fixes and a retest; it is not a certification or a legal conformity declaration.

Best for

  • A web or mobile app whose critical journeys have never been tested beyond an automated scan
  • A team that needs technical evidence for its own European Accessibility Act assessment

Consider another approach

  • A legal opinion on whether accessibility law applies to you
  • Ongoing functional and regression testing of every release

Sample complete journeys, not just pages

An audit is only as good as its sample. We pick the complete tasks people must finish (signing up, finding something, checking out, submitting a form with validation errors, downloading a document) and the templates and states those tasks touch: dialogs, expandable lists, error messages, empty results. Then we agree browsers, devices and assistive technologies. If you want to prepare that brief yourself or compare offers, use our buyer guide to scoping an accessibility audit.

Automated checks find some issues. People find the rest.

We evaluate against WCAG 2.2 at the level you choose, usually AA. Tools catch part of the problems; the rest needs a person working through the task.

Automated checks

Scanners across the sample for contrast, missing names, structure and misused ARIA. Every warning is triaged, because a tool result is not a finding until someone confirms it.

Keyboard and focus

Every task without a mouse: focus order, visible focus, keyboard traps in dialogs, skip links and where focus lands after an action.

Screen reader and zoom

Agreed screen reader and browser pairs (for example VoiceOver with Safari, NVDA with Firefox), text resizing and content reflow on narrow screens.

Native mobile apps

Where mobile is in scope: iOS and Android screens with the platform screen readers, larger system text sizes and touch target checks.

Findings your developers can reproduce and fix

Each finding records the page and state, environment, steps, observed and expected behavior, user impact, the WCAG criterion and a recommended repair. Findings are ranked by how much they stop someone completing the task, not by the number of tool warnings. You also get a tested-scope statement: what was evaluated, how, and what was not. The audit covers how the product works for disabled people; general functional and regression testing stays with Software QA.

Illustrative finding: a dialog that traps the keyboard

Illustrative, not an audited client page. A keyboard user opens a filter dialog but cannot reach its close control, so the page behind it becomes unreachable. The finding names the template and state, the browser and keyboard steps, the user impact, the expected focus behavior and WCAG 2.2 success criterion 2.1.2 No Keyboard Trap, with a proposed repair. After the fix, the retest repeats the whole task: open, use, close, and focus returning to the control that opened the dialog.

Audit, remediate, retest. Each is its own decision.

Scope and quote each phase separately. A sample gives evidence about the tested scope; it does not show that every page is accessible.

  1. Audit

    Receive the issue register, the tested-scope statement, method and environment details and a prioritized fix list.

  2. Remediation

    We fix the commissioned issues in your code, or your team fixes them using our findings and component guidance.

  3. Retest

    The original steps and neighbouring states are checked again. The register links each finding to its repair and retest result.
// proof

Accessibility inside product delivery

We have no published client accessibility audit yet. These cases are adjacent work, not WCAG conformance audits. Aniron: responsive layouts and accessibility addressed alongside functional delivery of a developer portal. Scramble Wallet: accessibility fixed as part of foundation work for non-crypto users aged 50+. Soundromeda: the reproduce, rank and retest discipline the findings format relies on.

Aniron

Live
Developer portal Customer onboarding, API-key controls, prepaid-credit top-ups and usage visibility delivered.

Wavect was the main contributor to Aniron’s developer application, covering API keys, prepaid credits, usage visibility and …

TypeScript Next.js React
AI 2026

Scramble Wallet

Live
50+ Target User Age

Multi-browser extension, Tron added, iOS + Android via multiple routes, built on a forked Enkrypt, debt paid down release by …

VueJS Typescript NestJS
FUNDS 2023

Soundromeda

Live
Production Vibe-Coded → Hardened

QA-led hardening took a vibe-coded game prototype to a state grant committees backed.

BLOCKCHAIN 2025

These are selected projects, not our full portfolio. We have shipped 100+ products since 2018.

Questions before you start

No. Scans find part of the issues and help prevent regressions. The tasks that matter still need keyboard, screen-reader and zoom testing by a person.
No. You get an issue register, a tested-scope statement and retest records. W3C does not certify WCAG conformance, and we do not declare legal conformity.
Only if you commission them. Audit, remediation and retest are scoped separately, so your own team can do the fixing.
Usually WCAG 2.2 level AA. We agree the target and any additional criteria in the proposal.
This is a separately scoped, newer offer and we have not published a client accessibility audit. The method follows W3C evaluation guidance, and the cases on this page show adjacent product work where accessibility was part of delivery.

Choose your next step

Scope your accessibility audit

Describe the product, the journeys that matter most and why accessibility is on the agenda now. A short, non-sensitive outline is enough for the first conversation.

Scope your accessibility audit →