Running an accessibility audit and remediation plan

An accessibility audit is a structured evaluation of a website or app against a standard, usually WCAG 2.2 level AA. A good audit does more than list failures. It shows where people are blocked, explains how to fix each problem and gives the team a realistic order to fix them in.

This lesson follows the W3C's Website Accessibility Conformance Evaluation Methodology (WCAG-EM) and adds the practical steps that turn findings into a plan.

The five steps of WCAG-EM

1. Define the scope of the evaluation.
2. Explore the website to understand it.
3. Select a representative sample of pages and processes.
4. Audit the sample against every success criterion.
5. Report the findings.

Step 1: define the scope

Agree these points in writing before testing starts:

• What is in scope: which domains, subdomains, apps and third-party parts, such as a payment provider or embedded booking widget.
• Target: usually WCAG 2.2 level AA. If a contract or law names an older version, include it; 2.2 AA covers 2.1 and 2.0 AA, apart from the obsolete 4.1.1 Parsing.
• Accessibility support baseline: the browsers and assistive technologies you will test with, for example NVDA with Firefox and Chrome on Windows, VoiceOver with Safari on macOS and iOS, and TalkBack with Chrome on Android.
• Purpose: a conformance check before launch, a baseline for a remediation programme, or evidence for an accessibility statement. The purpose decides how much detail you need.
• Timing and environment: which build or URL, and test accounts for logged-in areas.

Step 2: explore the site

Spend time using the site before you test it. Identify:

• the common components: header, navigation, footer, search, cookie banner, forms, cards, modals;
• the key tasks users must be able to complete: register, log in, search, buy, apply, contact;
• the page types: home, listing, detail, article, form, account, error pages;
• the technologies used: frameworks, embedded media, PDFs, maps, charts;
• pages with unusual content: data tables, calculators, interactive tools.

Step 3: select a representative sample

Testing every page of a large site is rarely possible. Choose a sample that covers:

• Common pages: home, contact, help, accessibility statement, login.
• One of each page type and template.
• Every complete process, end to end. A checkout is tested as a whole, from basket to confirmation, including errors along the way. WCAG conformance applies to complete processes.
• Every distinct component and state: open menus, error states, empty states, expanded accordions.
• A small random sample of other pages, to check that your structured sample really is representative.

For a typical marketing or content site, 15 to 30 pages and two or three processes often give a good picture. Record the exact URLs and states so the audit can be repeated.

Step 4: audit the sample

Combine methods, because each finds different issues.

Work through every WCAG 2.2 A and AA success criterion for each page, recording a result: Pass, Fail or Not applicable. A checklist built from the How to Meet WCAG quick reference, or a tool such as Accessibility Insights' assessment, keeps you thorough.

Recording an issue

A good issue lets someone who was not in the audit understand, reproduce, fix and retest it.

ID:            ISSUE-014
Title:         "Add to basket" buttons have no accessible name
Location:      Product listing template, e.g. /books/new
Component:     Product card
WCAG:          4.1.2 Name, Role, Value (A)
Severity:      Critical (blocks purchase for screen reader and voice control users)
Found with:    axe DevTools; NVDA with Firefox on Windows
Steps:         1. Open /books/new  2. Tab to the first product's basket icon
Actual:        NVDA announces "button" with no name. Voice control
               cannot target it.
Expected:      The button is announced as "Add to basket, Small Island, button".
Fix:           Add visually hidden text inside the button:
               <span class="visually-hidden">Add to basket, Small Island</span>
               and aria-hidden="true" on the icon.
Affects:       All product cards (about 40 pages use this template)

Write one issue per root cause, not per page. If a component template causes the problem everywhere, record it once and list where it appears.

Rating severity

WCAG levels tell you what the standard requires, not how badly users are affected. Add a severity rating based on impact.

Prioritising fixes

Combine severity with reach (how many users and pages are affected) and effort.

1. Critical issues in key journeys, such as login, checkout, contact and applications, come first, whatever the effort.
2. Shared components and templates next: one fix to the navigation or a form component removes the issue from every page.
3. High-impact, low-effort fixes, such as missing labels, alt attributes and the page language, can be batched quickly.
4. Content issues need editors, not developers: train them and fix the worst pages first.
5. Third-party components need supplier engagement: raise issues with the vendor, ask for their accessibility conformance report and plan alternatives.

A simple remediation plan lists each issue with an owner, a target release and a retest date. Track issues in the same backlog as other bugs, not in a separate spreadsheet that nobody opens.

Step 5: the report

A useful audit report contains:

1. A summary for decision makers: overall conformance, the most serious barriers, and the recommended priorities.
2. The scope and method: WCAG version and level, sample pages and processes, tools and assistive technologies, dates.
3. Results by success criterion: pass, fail or not applicable for each, across the sample.
4. The issues, each in the format above, grouped by component or journey.
5. Positive findings, so the team knows what to keep doing.
6. Next steps: the remediation plan and retest date.

The W3C's WCAG-EM Report Tool helps you structure this.

After the audit

• Retest each fix with the same method that found it, and record the result.
• Prevent regressions: add automated axe checks to the build, add keyboard and screen reader checks to the definition of done, and include accessibility in design reviews.
• Publish an accessibility statement that says which standard you aim for, known issues and when they will be fixed, and how people can report problems or get information in another format. Public bodies in many jurisdictions are required to publish one.
• Report formally if required. Organisations selling to public bodies are often asked for an Accessibility Conformance Report, commonly based on the VPAT template, which documents conformance criterion by criterion.
• Audit again after significant redesigns, and on a regular schedule, because new content and features introduce new issues.

Summary

• Follow WCAG-EM: define the scope, explore, select a representative sample, audit it and report.
• Include complete processes and every component state in the sample.
• Combine automated scans with keyboard, screen reader, zoom, content and media testing, and test every A and AA criterion.
• Write one clear, reproducible issue per root cause, with the WCAG criterion, severity, steps and a suggested fix.
• Prioritise by severity, reach and effort, starting with key journeys and shared components.
• Retest fixes, prevent regressions, publish an accessibility statement and audit again regularly.