How to Run an Accessibility Audit (Step by Step)

An accessibility audit is a structured evaluation of your site against a target standard — almost always WCAG 2.2 Level AA — that produces a prioritised, trackable list of issues to fix. Done well, it is not a single pass/fail verdict but a repeatable process: define scope and target, pick representative pages and flows, scan automatically, test manually with assistive technology, log each issue against its WCAG criterion with a severity, prioritise by impact and reach, remediate, and retest. And because a one-off audit decays as the site changes, the real goal is to bake the checks into your everyday workflow. This guide walks the whole process step by step.

It is the structured, repeatable version of the techniques in how to check if a website is accessible, grounded in the WCAG standard and its levels.

Step 1: Define scope and target

Before testing anything, decide two things.

The target standard. For almost everyone this is WCAG 2.2 Level AA — the level that delivers a genuinely accessible experience and that laws like the ADA and the European Accessibility Act effectively require. Writing the target down matters, because "make it accessible" is not testable but "conform to WCAG 2.2 AA" is. (If you are unsure why AA rather than A or AAA, see what WCAG is and the difference between A, AA and AAA.)

The scope. Which site, which sections, which functionality, on which platforms (desktop, mobile, perhaps a specific app), and against which browsers and assistive technologies. A clear scope keeps the audit finishable and the results comparable over time.

Step 2: Choose representative pages and flows

You almost never audit every page — and you do not need to. Most sites are built from a limited set of templates and a handful of critical user journeys, and testing those representatively finds the overwhelming majority of issues. Select:

• The home page and primary landing pages.
• Each distinct template — article, product, category/listing, search results, account, blog post.
• Every step of key flows end to end — sign-up, login, search, add-to-cart, checkout, contact, password reset.
• Complex and interactive components wherever they appear — forms, modals, carousels, accordions, date pickers, data tables, custom dropdowns.

Auditing a complete process matters: a checkout that is accessible on three steps but traps a keyboard user on the fourth is not an accessible checkout. Cover flows, not just isolated pages.

Step 3: Run automated scans

Start the actual testing with automated tools, because they are fast and clear the obvious issues before you invest manual time. Run axe DevTools, WAVE (WebAIM), and/or the Lighthouse accessibility audit on each selected page and capture the results. These reliably surface missing alt attributes, unlabelled form fields, contrast failures, empty links and buttons, missing page language and similar machine-detectable problems.

Keep the well-known ceiling in mind: automated tools catch only a portion of issues — commonly estimated at around 30 to 40% of WCAG problems — so this step is necessary but not sufficient. It is the foundation, not the finish. (A broad site report such as StackOptic can provide the automated WCAG layer alongside performance and SEO, which is a convenient starting input to an audit.)

Step 4: Do manual and assistive-technology testing

This is where the audit earns its value, by catching everything automation cannot judge. For each selected page and flow:

• Keyboard-only testing. Put the mouse aside and complete the task with Tab, Shift+Tab, Enter, Space and arrow keys. Check that everything is reachable and operable, the focus order is logical, the focus indicator is always visible, there are no keyboard traps, and skip links work. (The fixes are in how to make a website keyboard accessible.)
• Screen-reader testing. Use NVDA (Windows), VoiceOver (macOS/iOS) or JAWS. Listen for a logical heading outline, meaningful image descriptions, links that make sense out of context, properly labelled forms, announced errors, and announced dynamic updates.
• Contrast and colour. Verify text and meaningful UI meet 4.5:1 (normal) and 3:1 (large), and that colour is never the only means of conveying information.
• Zoom and reflow. Confirm content survives 200% zoom and narrow widths without clipping, overlap or loss of function.

Manual testing is what turns a scan into an audit, because it evaluates the actual experience rather than just the code.

Step 5: Log every issue against WCAG

Findings are only useful if they are recorded in a way that makes remediation unambiguous and progress measurable. For each issue, capture a consistent set of fields:

Field	Why it matters
ID	A stable reference for tracking and conversation
Location	Page/template and the specific element (a selector or clear description)
WCAG criterion	The exact success criterion it fails (e.g. 1.4.3 Contrast, 2.1.1 Keyboard) and level
Description	What is wrong and how it affects users
Severity	Critical / serious / moderate / minor — how badly it harms the experience
How to reproduce	Steps and the tool or assistive technology used
Recommended fix	A concrete remediation, so the developer is not guessing
Status	Open / in progress / fixed / verified

A worked example of a couple of log rows:

ID	Location	WCAG	Description	Severity	Recommended fix
A-001	Checkout step 2, card form	1.3.1 / 4.1.2 (labels/name)	Card-number field has no programmatic label; screen reader announces only "edit text"	Critical	Associate a <label> with the input (or aria-label) so its purpose is announced
A-014	Article template, body links	1.4.3 Contrast	Inline link colour on white is ~3.2:1, below the 4.5:1 minimum	Serious	Darken the link colour to meet 4.5:1; keep an underline so colour is not the only cue

Tying each issue to a specific WCAG criterion does two things: it removes ambiguity about whether something is "really" a problem, and it lets you report conformance precisely.

Step 6: Prioritise by impact and reach

You cannot fix everything at once, so order the work by impact multiplied by reach:

• Impact is how severely the issue harms users. A keyboard trap, an unlabelled checkout field, or content that is completely inaccessible to a screen reader blocks people from a task entirely — critical. A minor contrast miss on secondary text degrades but does not block — low.
• Reach is how many users hit it, which usually tracks page traffic and whether the issue sits in a core flow. A problem on the checkout or sign-up affects far more people than one on a buried legal page.

The top of the queue is therefore high-impact issues on high-traffic, business-critical pages and flows — the blockers everyone encounters. The bottom is low-impact issues on rarely visited pages. This ordering ensures the first fixes deliver the most real-world accessibility gain per hour of effort.

Step 7: Remediate

With a prioritised, well-described log, remediation becomes ordinary engineering work. Assign issues, fix them according to the recommended remediation, and prefer root-cause fixes over one-off patches — if an unlabelled-field pattern recurs across forms, fix the shared form component, not each instance. This is where an accessible design system pays off: fixing a button, input or modal component once propagates the fix everywhere it is used. Group related issues so a developer can resolve a whole class in one pass rather than ticket by ticket.

Step 8: Retest and verify

A fix is not done until it is verified. Re-run the relevant automated scan and, crucially, repeat the manual test that found the issue — re-do the keyboard pass, re-listen with the screen reader, re-check the contrast. Mark each issue verified only when it genuinely passes, and watch for regressions elsewhere, since changes can introduce new problems. Retesting closes the loop and confirms the audit produced real improvement rather than just a document.

Step 9: Bake it into the workflow

The hardest truth about audits is that they decay. A site that conforms today drifts out of conformance as features ship, content is added and third-party scripts creep in. So the durable goal is not a perfect one-off audit but accessibility built into how you work:

• Automated checks in CI. Run axe or similar in your test pipeline so obvious regressions fail the build before release.
• Accessible components in the design system. Make the default building blocks accessible so most new work is accessible by construction.
• Accessibility in the definition of done. Treat keyboard operability, labels, contrast and alt text as acceptance criteria, not afterthoughts.
• Periodic deep audits. Schedule a full manual audit annually and before major redesigns or new flows, since automation only ever covers part of the picture.

This combination — continuous automated guardrails plus periodic human audits plus accessible defaults — is what keeps a site accessible over time rather than sliding back after every release.

Roles and cadence

A quick word on who does what. Automated checks suit developers and CI and should run constantly. Manual keyboard and screen-reader testing suits QA, developers and dedicated accessibility specialists, and benefits enormously from involving people with disabilities where possible, since lived experience surfaces issues testers miss. Cadence: automated on every change, a structured manual audit periodically and before big launches, and spot checks whenever a new interactive component is built. The point is a rhythm, not a single heroic effort.

A compact audit checklist

• Target set (WCAG 2.2 AA) and scope defined.
• Representative pages and full key flows selected.
• Automated scans run and captured (axe / WAVE / Lighthouse).
• Keyboard-only pass completed for each flow.
• Screen-reader pass completed (NVDA / VoiceOver / JAWS).
• Contrast, colour-only cues, zoom and reflow checked.
• Every issue logged with WCAG criterion, severity, location and fix.
• Issues prioritised by impact times reach.
• Remediation done at root-cause level; design-system components fixed.
• Retested and verified; regressions checked.
• Checks added to CI and definition of done; next audit scheduled.

The bottom line

A good accessibility audit is a disciplined loop, not a one-time verdict: define a clear target (WCAG 2.2 AA), test representative pages and complete flows both automatically and manually, log each issue against its WCAG criterion with a severity, prioritise by impact and reach, remediate at the root cause, and retest. Then, because audits decay, fold the checks into CI, your design system and your definition of done so the site stays accessible as it grows. For the techniques behind each test, see how to check if a website is accessible; for the foundations, what web accessibility is and why it matters.

Want an automated WCAG accessibility check to seed your next audit, alongside SEO and performance? Analyse any URL with StackOptic — one report, free, no sign-up.