WCAG audit: how a web accessibility audit works

What a WCAG audit includes

An audit is a structured, written evaluation, not a quick scan. A typical web accessibility audit has five parts:

• An agreed standard and level, usually the AA level of WCAG 2.2, or of 2.1 when a law names it, sometimes mapped to EN 301 549 or GIGW.
• A defined scope: which pages, templates, user journeys, documents and apps are in and out.
• Testing: automated tools to clear the obvious, then manual review of every criterion at the chosen level, using a keyboard, zoom and at least one screen reader on desktop and on a phone.
• A report listing every issue with its criterion, location, severity, user impact and a suggested fix.
• A retest after you fix things, to confirm the issues are closed.

If you just want to know how testing works, read web accessibility testing first. An audit is that same work done formally and documented for others to rely on.

Choosing the scope and sample

Few sites can be audited page by page. Auditors work from a representative sample, an approach W3C describes in its evaluation resources. A good sample includes:

• One page of each template: home, category or listing, article or product detail, search results, contact.
• Every step of the main user journeys: sign up, sign in, checkout, booking, payment, account settings.
• Shared parts such as the header, footer, menus, cookie banner, chat widget and modal dialogs.
• A few randomly chosen pages, to catch problems the planned sample misses.
• Downloadable documents and embedded third-party content that users need to complete a task.

How the audit is carried out

Methods vary, but a careful auditor works through each sampled page roughly like this. First, automated tools such as axe or WAVE to collect code-level errors. Next, a criterion-by-criterion manual review: keyboard operation, focus order and visibility, reflow at 400 percent, text spacing, contrast of text and controls, headings and labels, form errors and status messages. Then assistive technology checks, typically a desktop screen reader with two browsers, plus the screen reader that ships with an iPhone or Android phone. Some audits add voice control or magnification.

Each issue is logged once per component with every place it appears, so you fix the cause rather than counting symptoms. The WCAG checklist shows the 55 criteria an AA audit walks through.

What a good audit report contains

VPAT, ACR and accessibility statements

An audit often feeds other documents. Companies that sell software to US agencies, universities or EU public bodies complete the VPAT form (the letters stand for Voluntary Product Accessibility Template). The finished document is known as an Accessibility Conformance Report, or ACR, and states criterion by criterion how far the product supports WCAG, EN 301 549 or the Section 508 rules. Public sector sites in the UK and EU are also required to post an accessibility statement naming the gaps that remain and giving people a contact route for reporting barriers. Both should be based on a recent audit rather than guesswork. The WCAG compliance page explains how claims work.

Who can audit: qualifications and empanelled auditors

There is no licence for accessibility auditors, but certifications help you judge skill. IAAP (International Association of Accessibility Professionals) offers CPACC for core knowledge, WAS (Web Accessibility Specialist) for hands-on technical testing, and CPWA for people who hold both. In the US, the Department of Homeland Security's Trusted Tester certification covers a Section 508 test process. Ask who will do the testing, what credentials they hold and whether screen reader users are on the team.

In India, some government and public sector buyers ask for an auditor from an empanelled list, for example lists linked to the Department of Empowerment of Persons with Disabilities (DEPwD) or to GIGW compliance. Lists and rules change, so ask the buying department for its current list and requirements, and check the GIGW site. Entities regulated by SEBI should read the latest SEBI circular for who may carry out their audit.

After the audit: fixing and retesting

An audit report is a snapshot. The real value comes from what happens next. Start with barriers that stop people finishing the main journeys, then shared components, then single-page issues. Ask developers to confirm each fix by keyboard and with a screen reader, then book a retest so the auditor can close issues formally. To keep results from slipping, train content editors, add automated checks to your build, and repeat a lighter audit when you redesign or add major features. The accessibility services guide covers remediation and monitoring providers.

What makes an audit bigger

Quotes vary widely, so compare scope rather than headline figures. The things that add effort are the number of unique templates and journeys, the number of custom interactive components, native apps on two platforms, PDFs and other documents, the number of languages, and whether retests and a VPAT are included. Content that changes daily means an audit ages quickly, so plan for follow-up reviews.