What actually happens in a WCAG audit
An accessibility audit isn't a scan you run and forget. Here's what a real one involves — and what you get out of it.
“Accessibility audit” can mean very different things depending on who’s doing it. At one end is a button you click that spits out a list of automated warnings. At the other is a careful, human evaluation of whether people can actually use your site. This is what the second kind looks like.
It starts with scope, not scanning
Before any testing, we agree on what matters: the key user journeys (sign-up, checkout, search), the page templates that repeat across the site, and the components that show up everywhere. Testing every page is rarely useful — testing the right representative set is.
Most of the work is done by hand
Real barriers tend to hide where automated tools can’t reach:
- Can you complete every task using only a keyboard?
- Does a screen reader announce things in an order that makes sense?
- Do focus states show you where you are?
- Does the page still work zoomed to 200% or on a narrow screen?
These questions need a person, because they’re about experience, not just markup.
You get findings you can act on
The output isn’t a raw dump. Each issue is tied to a specific WCAG success criterion, rated by how badly it affects people, and paired with a concrete fix. The goal is a report your team can pick up and work through — starting with what matters most.