How to Run an Accessibility Audit

Accessibility gets filed as a compliance chore, which is exactly why it ships broken. Framed as a checkbox, it becomes something to do later. Framed correctly — as usability for the full range of people who'll actually use your product — it's just good UX, and it happens to be the single most common thing teams get wrong in ways they never notice.

The good news: most accessibility problems live in the code, which means they're findable and fixable with a systematic audit. This is how to run one, what it should check, and the handful of fixes that resolve the majority of real issues.

What an accessibility audit checks

A useful audit is organized around whether people can actually perceive, operate, and understand your interface — the backbone of the WCAG guidelines. Concretely, it looks at:

• Names and labels — every form control has a programmatic label; every icon-button and link has an accessible name.
• Color contrast — text meets the required ratio against its background so it's readable in real conditions, not just on the designer's monitor.
• Semantic structure — real headings, lists, landmarks, and buttons, so the page has meaning beyond its pixels.
• Keyboard operability — everything works without a mouse, in a logical order, with a visible focus indicator.
• Images and media — meaningful images have alt text; decorative ones are correctly hidden.
• Correct ARIA — used only where needed and not breaking native semantics (bad ARIA is worse than none).

Accessibility isn't a feature you add. It's a property of code you either wrote well or didn't.

Why you need automated and human testing

Be honest about what automation can and can't do. Automated checks are excellent at the objective, machine-detectable failures — a missing label, an insufficient contrast ratio, an empty alt attribute — and they'll find a large share of issues in seconds. But some criteria require judgment a tool can't supply: whether alt text is meaningful, whether the focus order tells a coherent story, whether an interaction is genuinely understandable. The right process is automated-first to clear the detectable problems fast, then human verification with a keyboard and a screen reader for the rest.

How to run one, start to finish

1. Audit the code. Run an automated pass over the actual markup and CSS to surface labels, contrast, semantics, and structure issues, each mapped to the relevant WCAG criterion.
2. Fix at the source, with code. Resolve findings in the markup — add the <label>, fix the ratio, replace the <div> with a <button> — rather than papering over them with ARIA.
3. Test by keyboard. Tab through every flow. Can you reach and operate everything, in order, with a focus indicator you can see?
4. Test with a screen reader. VoiceOver or NVDA will tell you immediately whether your names, roles, and structure actually make sense.
5. Re-audit and guard against regression. Confirm the fixes, and add a check so the same issues can't quietly return.

The highest-impact fixes

A small number of fixes resolve a disproportionate share of real-world barriers. If you do nothing else, do these:

• Label every input. A real <label> (or an accessible name) on every field. This alone fixes a huge fraction of form failures — and forms are where conversions live.
• Fix contrast. Bring low-contrast text up to ratio. It helps everyone, everywhere, on every screen.
• Use semantic elements. Buttons that are <button>, headings that are headings. Native semantics are free accessibility.
• Make focus visible. Never remove focus outlines without replacing them; keyboard users navigate by them.

Frequently asked