An accessibility audit asks: does this meet the standard? Usability testing asks something different: can people actually get this done? Most of the time the answers line up. But the gaps between them are where some of the most expensive problems live.
Conformance and usability aren't the same thing
WCAG is a brilliant, hard-won standard. It's also, by design, a set of testable rules. It can tell you a form field has a label. It can't tell you whether the label makes sense to someone hearing it out of context, or whether the form's twelve fields in a row are exhausting to get through with a screen reader.
A few patterns we see often:
- A form that technically announces its errors, but only after the user has tabbed past every field, so they have to go hunting for what went wrong.
- A navigation menu that works with a keyboard, but takes 40 presses of Tab to get past on every single page.
- Accurate alt text on a chart that doesn't carry the one insight the chart exists to show.
- A verification step that's accessible in principle but times out before a screen-magnifier user can find the code on their screen.
None of these would necessarily fail an audit. All of them cost people time, confidence, and sometimes the whole transaction.
Why it has to be disabled people
Specialists can simulate a lot. We use screen readers every day, and a good auditor catches most barriers. But someone who has used a screen reader for fifteen years moves through an interface differently from someone testing with one. They skim by headings, jump by landmarks, and have built up strategies — and frustrations — no checklist captures.
There's also a principle at stake. The disability rights movement has a phrase for it: nothing about us without us. If you're building for disabled people, they should be in the room when you find out whether it works.
How to run it well
Pick one journey that matters
Don't try to test everything. Pick the flow where failure costs the most — sign-up, KYC, checkout, booking, submitting a claim — and go deep on it. One well-run study on a critical journey is worth more than a shallow pass over the whole product.
Recruit for the ways people actually use technology
Aim for a spread: someone who uses a screen reader, someone who uses magnification or high zoom, and someone who navigates by keyboard, switch, or voice. Match your real audience where you can — a retirement platform should include older users, and a banking app should include people on mobile.
Let people use their own setup
People's devices, screen readers, speech rates, and settings are tuned to them. Asking someone to use an unfamiliar laptop tests the laptop, not your product. Remote moderated sessions make this easy: participants join from their own device, share their screen and audio, and work the way they always do.
Give tasks, not instructions
"Open an account and add a nominee" is a task. "Click the blue button in the top right" is an instruction, and it tells you nothing. Then stay quiet. The moments where someone pauses, backtracks, or says "hmm" are the most valuable in the whole session.
Pay people properly
Disabled participants are experts in how products fail them, and their time should be paid like expert time. Paying fairly is the right thing to do, and it's also how you build a pool of people who want to work with you again.
How many participants do you need?
Fewer than you'd think. Three to five people on a single journey will surface most of the serious problems, because serious problems tend to trip almost everyone. The aim isn't statistical proof. It's to see the barriers clearly enough to fix them — and then to test again.
What you get out of it
- Findings ranked by impact on real people, not just by WCAG level
- Short video clips that make the case to stakeholders far better than any report
- Barriers an audit alone would have missed
- A team that has watched someone use their product with assistive technology — which tends to change how they build forever
That last one matters most. Once a developer has watched someone try, and fail, to get through a form they built, accessibility stops being a ticket in the backlog. It becomes something they care about.