What Is a Website Accessibility Audit? The Process, Step by Step

A website accessibility audit is a structured review of your website against the Web Content Accessibility Guidelines (WCAG), carried out by a person. The auditor uses your site the way disabled people do, with a keyboard only, with screen readers, zoomed in to 400%, and with contrast tools, and records every barrier they find. Automated tools are part of the process, but they are not the audit.

What you get at the end is a report. Each issue has its location, the WCAG success criterion it fails, how severe it is, who it affects and how to fix it. A good audit also includes a re-test after your team has made the fixes, so you know the barriers are actually gone.

This guide walks through what an accessibility audit is, the standard it tests against, the WCAG audit process from scoping to re-test, what the deliverables look like, how long it usually takes, and how to prepare so the auditor's time goes where it matters.

Accessibility audit vs. automated scan

The two are often sold under the same name, so it helps to be clear about the difference. An automated scan runs a set of rules against your page code. It is fast, cheap or free, and good at catching problems that can be detected mechanically, such as an image with no alt attribute or a form field with no label.

What a scan can't do is judge. It can tell you an image has alt text, but not whether the alt text makes sense. It can't tell you whether a keyboard user can open your menu, whether a screen reader announces an error message, or whether a checkout can be completed at all. The W3C puts it plainly: evaluation tools cannot determine accessibility, they can only assist in doing so. We go into the detail in automated vs. manual accessibility testing.

A scan is still a useful first step. Our free automated accessibility scan takes a minute and will surface the issues a machine can find, which you can fix before an auditor ever looks at the site.

What standard does a WCAG audit test against?

Almost every website accessibility audit tests against WCAG, published by the W3C. WCAG is organized into success criteria, each at Level A, AA or AAA. Level AA is the target in nearly every law and procurement policy; Level AAA is rarely required for a whole site.

WCAG 2.2 is the current W3C Recommendation. In Ontario, the legal baseline is older: under the AODA's Integrated Accessibility Standards, public sector organizations and businesses and non-profits with 50 or more employees must make their public websites meet WCAG 2.0 Level AA. Two criteria are exempt: 1.2.4 Captions (Live) and 1.2.5 Audio Description (Prerecorded). AODA does not require WCAG 2.1 or 2.2. Our AODA requirements guide covers who is affected and the deadlines.

So why do most auditors, us included, test to WCAG 2.2 AA? Because each version of WCAG builds on the last. A site that meets 2.2 AA also meets every 2.0 AA criterion the AODA asks for, so one audit covers your legal baseline and the newer criteria that buyers, procurement teams and the rest of the world increasingly ask for. A good report marks which findings fall inside the WCAG 2.0 AA baseline, so you can see your legal exposure separately from best practice.

One detail from WCAG itself shapes how audits work: conformance applies to full pages and to complete processes. If one step of your checkout fails, the checkout as a whole doesn't conform, even if the other steps are perfect. That's why auditors test whole journeys, not just individual pages.

The WCAG audit process, step by step

Methods vary between auditors, but most follow the shape of the W3C's WCAG Evaluation Methodology (WCAG-EM): define the scope, explore the site, select a representative sample, evaluate it, and report. Here is what each stage looks like in practice.

1. Scoping by templates and user journeys

Most websites are built from a small number of templates. A template is one distinct layout or screen: your home page, a product page, the checkout, a sign-up dialog. Two hundred product pages built on the same layout count as one template, because a barrier in the template is a barrier on all two hundred.

So rather than testing every page, the auditor and you agree on a representative sample: every distinct template, plus the user journeys that matter most to your business, tested from start to finish. WCAG-EM also recommends adding a small random sample on top of the structured one, as a check that the structured sample really is representative.

Example scope for a physiotherapy clinic: home page, a service page, the team page, a blog article, the contact page, and the online booking flow from "Book now" to the confirmation screen. That's five templates and one key journey, which together cover nearly every component on the site.

Scoping also fixes the standard (for example, WCAG 2.2 AA), the browsers and assistive technologies to test with, and any extras, such as PDFs or a sign-in area.

2. The automated pass

The auditor runs automated tools across everything in scope. This clears the mechanical issues quickly (missing labels, empty buttons, some contrast failures, invalid ARIA) so the manual time can go to the problems only a person can find.

3. Manual testing

This is the core of the audit, and where most of the important findings come from.

• Keyboard only. Can every link, button, menu and form control be reached and used with the Tab, Enter, Space and arrow keys? Is the focus always visible, and does it move in a logical order? Can you get out of every dialog? (2.1.1 Keyboard, 2.1.2 No Keyboard Trap, 2.4.3 Focus Order, 2.4.7 Focus Visible.)
• Screen readers. Testing with tools such as JAWS and NVDA on Windows, VoiceOver on Mac and iPhone, and TalkBack on Android. Do headings, landmarks and links make sense when read aloud? Are buttons announced with a name and a role? Are errors and status updates announced? (1.1.1 Non-text Content, 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value.) Our screen reader testing guide explains how this works.
• Zoom and reflow. At 200% text size and at 400% zoom, does everything stay readable and usable without scrolling sideways? (1.4.4 Resize Text, 1.4.10 Reflow.)
• Colour and contrast. Body text needs a contrast ratio of at least 4.5:1, large text 3:1, and icons and form borders 3:1. Is colour ever the only way information is shown? (1.4.1 Use of Color, 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast.)
• Forms and errors. Do fields have visible labels, are errors described in text, and is it clear how to fix them? (3.3.1 Error Identification, 3.3.2 Labels or Instructions.)
• Media and content. Do videos have captions? Are link texts meaningful out of context? Is the page language set?

4. Documenting the issues

Each barrier is written up as a finding: where it is, what was observed, which success criterion it fails, how severe it is, who it affects and how to fix it. Severity usually runs from critical (someone can't complete a task at all) through serious and moderate to minor. Issues that come from a shared component are reported once, against the component, rather than repeated on every page it appears on.

5. Walkthrough and re-test

The auditor walks your team through the findings, answers questions, and, once your developers have made the fixes, re-tests each finding to confirm it is resolved. Without that re-test, you have a list of problems, not evidence that they've been fixed.

What the deliverables look like

The main deliverable is a findings report, usually as a PDF and a spreadsheet so the findings can go straight into your issue tracker. It should open with a plain-language summary for leadership: where the site stands, and the few barriers to fix first. Then comes one entry per finding, written for developers.

Finding: Keyboard users can't choose a pickup time, so they can't order.
Where: Order form, step 2.
Severity: Critical.
Who it affects: Keyboard users, switch users, many screen reader users.
How to fix it: Replace the custom time picker with a native select, labelled "Pickup time".
WCAG: 2.1.1 Keyboard (Level A).

You can read a full example in our sample accessibility audit report. If a customer or public-sector buyer has asked for proof of accessibility, the audit can also be the basis for an Accessibility Conformance Report (ACR), often called a VPAT: a standard document that states, criterion by criterion, how your product conforms.

How to prepare for an accessibility audit

A little preparation makes the audit faster, cheaper and more useful. Before it starts, work through this accessibility audit checklist:

• List your templates. Walk the site and note each distinct layout, not each page. This is the single biggest factor in the scope.
• Pick your key journeys. Which tasks must a customer be able to finish? Booking, buying, applying, signing up, paying a bill, contacting you.
• Decide the standard. WCAG 2.2 AA covers the AODA baseline and most buyer requirements. Tell the auditor if a contract names something else, such as Section 508 or EN 301 549.
• Set up access. A stable staging link, test accounts, test payment details and any sign-in steps the auditor will need. Avoid big releases during the testing window.
• Fix the easy things first. Run a free scan and clear the automated failures, so the audit doesn't spend time documenting missing alt attributes.
• Name one contact. Ideally a developer who knows the front-end code, to answer questions and receive the report.
• Gather your documents. If PDFs or forms are part of a journey, flag them; documents are usually scoped separately.
• Say what you need it for. An AODA compliance report, a procurement response, a redesign? The answer changes what the report should emphasize.

How long does an accessibility audit take?

It depends on scope far more than on the size of the site. As a rough guide, an audit of a single key journey across a handful of templates can be delivered in about a week. A full audit of a typical business site or web app, with ten to twenty templates and a few journeys, usually takes two to three weeks. Large applications, several platforms or an ACR on top add time. Remediation and the re-test then depend on how quickly your team can make the fixes.

Be wary of anyone promising a full manual audit of a complex site in a day or two. That usually means the manual part is thin.

What happens after a website accessibility audit

The report is the start of the work, not the end. Your team triages the findings, fixes the critical barriers in shared components first, and works through the rest in priority order, then the auditor re-tests. We cover how to plan that in how to build an accessibility remediation plan.

Keep in mind that an audit is a snapshot. Every new template, plugin or content change can introduce new barriers, so build accessibility checks into how you design, develop and publish, and re-test after major changes.

Frequently asked questions