Accessibility Audits: Process and Remediation Prioritization

The plain-language idea

A genuine accessibility audit typically combines three layers, not one:

• Automated scanning — tools like the axe-core-based tooling covered earlier in this track, run against real pages, catching a real and useful subset of issues (contrast, missing labels, invalid ARIA) fast and cheaply.
• Manual expert review — a person who knows WCAG and real assistive-technology behavior going through the product's actual flows, catching what automation structurally can't: whether a focus order makes sense, whether an error message is genuinely understandable, whether a custom widget behaves the way its ARIA role promises.
• Testing with actual assistive-technology users — ideally, real people who use screen readers, switch devices, or voice control day to day, using the actual product. This layer catches gaps that even an accessibility expert without lived daily AT experience can miss.

Automated tooling alone, covered in this track's earlier testing lesson, only catches a subset of real issues — that's exactly why a genuine audit needs the manual and real-user layers too. Skipping either one and calling the result a complete audit is a common, real gap between "we ran a scanner" and "we did an audit."

See it in a real thing: a findings list with 80 issues

Imagine an audit of a large, several-years-old product comes back with eighty findings, spanning every conformance level from A to AAA. No team fixes eighty issues at once, so the real question becomes: what gets fixed first?

The practical framework is severity × reach, not conformance level alone:

• Severity — does this completely block a task for some users (a form that can't be submitted at all via keyboard), or is it a minor inconvenience (a slightly ambiguous but still functional label)?
• Reach — does this affect a core, high-traffic flow like checkout or login, or a rarely-visited settings sub-page?

A Level A issue that blocks checkout for keyboard users is a far higher real-world priority than a Level AA issue on an obscure settings page, even though "A" technically sounds like a lower bar than "AA." Sorting a findings list by conformance level alone — fix all the A's, then all the AA's — ignores this and can easily mean shipping fixes to rarely-used pages before fixing something blocking the product's most important flow.

What people usually miss

Watch out

• A large legacy product's first real audit often surfaces more findings than can be fixed immediately — that's normal, not a sign the audit failed. The audit's value comes from what actually gets fixed and in what order, not from the length of the findings list itself.
• Conformance level (A/AA/AAA) is not a prioritization axis by itself. It's useful for describing a rule's strictness, but severity and reach — real user impact — are what should actually drive fix order.
• Automated scanning alone is not an audit. A team that runs a scanner, fixes what it flags, and calls the product "audited" has done real, useful work, but has skipped the manual and real-AT-user layers that catch a different and often more serious category of issue.
• "We'll get to the rest eventually" without a defensible priority order tends to mean the most-visible, easiest fixes happen first — not the most-impactful ones. A severity-times-reach framework exists specifically to counter that natural drift.

Why this matters in interviews

"You inherit a findings list of sixty accessibility issues on a legacy product. How do you decide what to fix first?" is a real, practical question, and answering with a severity-and-reach framework — rather than "start from the top" or "fix all the Level A issues first" — signals a candidate who has actually run remediation work, not just an audit.