How to Do an Accessibility Audit and Write the Report

An accessibility audit should produce decisions, not just a list of scanner warnings. Teams need to know which users encounter a barrier, how to reproduce it, which requirement applies, and what evidence will demonstrate a successful fix. A useful report makes those questions answerable without another discovery meeting.

Define the scope and evidence standard

Agree on the target standard, product version, environments, and boundaries before testing. For example, specify WCAG 2.2 Level AA, the authenticated customer application, two supported browser combinations, and the checkout process. Identify exclusions explicitly, including third-party content; exclusion from your test scope does not automatically exclude content from conformance responsibilities.

Use the contrast checker for reproducible foreground/background measurements during visual review. Record the colors, text size, weight, and state rather than pasting only a passing badge. A ratio for the default state says nothing about a disabled-looking error message or a focused control on another surface.

Follow the WAI evaluation methodology to structure scope, sampling, evaluation, and reporting. Distinguish a sample-based evaluation from an exhaustive review. Testing ten pages cannot justify an unsupported claim that every page in a large product conforms.

Use the existing accessible interface guide to align terminology with the delivery team. Agree on issue severity and what counts as sufficient evidence before the findings arrive, so the report does not become a debate about labels.

Build a representative sample of pages and states

Inventory templates, shared components, critical journeys, and unusual interactions. Include the home page, search, account settings, forms, data tables, dialogs, and any task that creates a financial or irreversible commitment. Add a small random sample to catch patterns the initial inventory missed.

Sample complete processes, not only convenient landing pages. A booking flow includes date selection, validation, payment, confirmation, and recovery after a failed submission. Obtain safe test accounts and test data before starting. Never run destructive checks against real customer records merely to complete an audit checklist.

For each sampled page, capture important states: empty, populated, loading, error, success, expanded navigation, and open overlays. Record responsive layouts and zoom conditions. A dialog's closed trigger can pass every automated check while the open dialog creates a keyboard trap.

Create a test matrix listing page or process, state, environment, test method, and result. Distinguish not tested, not applicable, pass, and fail. An empty cell should never silently mean pass. Keep authentication instructions and sensitive screenshots out of broadly shared reports; link to appropriately restricted evidence instead.

Combine automated checks with manual task testing

Run an automated accessibility scanner across representative routes and states. Use its results as leads for human verification. Duplicate IDs, missing names, and some contrast issues can be detected automatically, but a tool cannot reliably decide whether an alternative text conveys the right meaning or a workflow is understandable.

Use WAI's evaluation tools guidance when selecting tools, and document scanner versions and settings. Avoid treating a tool score as a percentage of WCAG conformance. Different engines cover different rules and can report different counts for the same underlying defect.

Then perform a structured manual pass:

1. Navigate without a pointer, including reverse tabbing and escape behavior.
2. Check focus visibility, sequence, overlay obstruction, and focus restoration.
3. Review headings, landmarks, link purpose, and accessible names.
4. Submit forms with missing and invalid values, then correct them.
5. Inspect zoom, reflow, text spacing, target size, and visual contrast.
6. Run key tasks with representative screen-reader and browser combinations.

For screen-reader testing, record the pairing and version rather than saying only “tested with assistive technology.” Learn expected interaction patterns before reporting a defect: browse-mode navigation and form-control interaction are not interchangeable. Include disabled users in usability research where possible; their participation adds insight but does not replace criterion-by-criterion evaluation.

A lightweight test can protect a known naming requirement after manual investigation:

import { test, expect } from "@playwright/test";

test("search has a named input and submit action", async ({ page }) => {
await page.goto("/search");
await expect(
  page.getByRole("searchbox", { name: "Search articles" })
).toBeVisible();
await expect(
  page.getByRole("button", { name: "Search", exact: true })
).toBeEnabled();
});

This checks a narrow contract, not complete search accessibility. It will not establish that results are announced correctly or that focus behaves sensibly after submission.

Write findings developers can reproduce

Give every finding a stable identifier and a short, specific title. “Checkout error summary does not receive focus after invalid submission” is more actionable than “ARIA problem.” Include the affected URL or route, component, state, environment, and any prerequisites needed to reproduce it.

Write numbered reproduction steps, actual behavior, expected behavior, user impact, relevant WCAG criterion, and recommended remediation. Reference the normative WCAG 2.2 requirements rather than guessing criterion numbers from a scanner label. Keep implementation advice separate from the requirement: several valid fixes may exist.

Describe the user barrier directly. For example: “A keyboard user submits the form, but focus remains below the error summary, so the missing-field guidance is not encountered in the next navigation steps.” Include concise screenshots, DOM excerpts, or recordings where they clarify the evidence, without exposing private data.

Group repeated instances under a shared root cause when the remediation belongs in a reusable component. Still list representative locations and known exceptions. One broken button component may affect hundreds of pages, but reporting hundreds of identical findings can obscure the work rather than prioritize it.

Prioritize remediation and report limitations honestly

Separate severity from conformance level. An A failure is not automatically more severe than an AA failure. Rank issues by task blockage, frequency, reach, availability of a workaround, and the importance of the affected process. Explain your severity definitions so readers understand the judgment.

Provide an executive summary with the scope, major barriers, affected journeys, and recommended next steps. Follow it with methodology, environments, findings, and limitations. Avoid a blanket compliance certificate when the sample or test depth does not support one. An accessibility statement is also not a substitute for the underlying evidence.

Assign each finding an owner and acceptance criteria. Use statuses such as open, fixed awaiting retest, verified fixed, and deferred with rationale. A merged pull request is not verified remediation. Retest the original steps, relevant variants, and nearby interactions that the change might affect.

Keep reusable lessons in the accessibility category resources and the team's component guidance. Schedule regression checks for shared controls and high-risk journeys. Close the audit with a dated report version and an explicit list of unresolved findings, so future readers can distinguish the tested baseline from later product changes.

Key takeaways

• Scope the audit explicitly, including versions, environments, and complete processes.
• Combine scanners with keyboard, visual, and assistive-technology testing.
• Record reproducible evidence and the user impact of each finding.
• Separate normative failures from implementation suggestions and severity judgments.
• Assign owners, define acceptance criteria, and retest fixes.
• State limitations instead of overstating what a sample can prove.