How to prepare your team and your product for a successful review.
Most teams start preparing for a WCAG compliance review about a week before it happens. That's usually the single biggest reason the review goes badly.
A compliance review isn't an exam you cram for the night before. It behaves more like a fire drill: how it goes depends almost entirely on what's already in place, not on what gets patched together once the date lands on the calendar. Reviewers aren't grading a snapshot — they're testing whether accessibility is something your product actually has, or something your team is currently trying to fake for an afternoon.
If a review is coming up, here's what actually moves the needle, and what's mostly wasted motion.
Work backward from the review date, not forward from today.
Start with the calendar, not the checklist
Eight weeks out, get a baseline. Run an actual audit — not a five-minute scan — and find out where the product genuinely stands. Skipping this step is how teams walk into remediation guessing at priorities instead of working from evidence.
Four weeks out, remediate in order of severity, not order of convenience. A keyboard trap on the checkout page outranks a missing alt attribute on a footer icon, even if the icon is faster to fix. Reviewers notice when the easy issues got cleaned up and the hard ones didn't.
One week out, run a dry rehearsal of the exact path a reviewer will take: sign up, log in, complete the core task, hit an error, recover from it. Do this with a keyboard only, then again with a screen reader. Anything that breaks here is still fixable. Anything that breaks during the actual review is a finding.
On the day itself, your job is logistics, not last-minute engineering. Confirm test accounts work, confirm the right people are dialed in, and resist the urge to ship a fix an hour before the call starts. A last-minute change nobody's tested is how a team turns one known issue into two unknown ones.
Get the right people in the room early
A review goes sideways fastest when a reviewer asks a direct question and the person on the call has to go find out. Assign ownership before the date is set, not the morning of.
Who answers which question matters as much as who did the work.
This doesn't mean every meeting needs four departments present. It means everyone on the call knows which questions are theirs to answer, and which ones they're allowed to say "let me follow up" to — which sounds far more credible than a guess that turns out to be wrong.
Know what "ready" actually looks like
Teams often confirm the wrong thing before a review. They check that a feature exists — alt text is present, a label is present, focus styles are present — without checking that it works the way it's supposed to. Presence and function aren't the same test.
Five areas worth checking yourself before someone else checks them for you.
Run through these five with a critical eye, not a confirming one. The goal isn't to verify these things exist somewhere in the code. It's to verify they hold up when someone actually depends on them.
The mistakes that sink an otherwise solid review
A few patterns show up again and again in reviews that don't go well, even for products that were mostly in decent shape:
- Leaning entirely on an automated scan result as proof of readiness, when scanners only catch a portion of what actually blocks a task
- Testing only the happy path — the flow works fine until someone hits a validation error, and nobody checked whether that error gets announced
- Forgetting about third-party widgets and embeds — a chat plugin or a payment iframe your team didn't build but that's still part of the experience a reviewer will test
- Treating a VPAT or conformance document as a marketing artifact instead of an honest account of where gaps remain
- Having nobody on the call who can speak to how an issue actually gets fixed, only that it's "on the roadmap"
What a reviewer actually does
It helps to know the shape of the review itself, rather than picturing a single checklist getting marked off top to bottom.
Four passes through the same product, not one pass with a checklist.
The keyboard walk-through and screen reader checks are what most teams expect. The page sampling catches teams off guard when a reviewer picks pages nobody prepped specifically — which is exactly the point, since a product that only performs well on rehearsed pages isn't actually ready. The process questions catch teams off guard the most: how did you find this issue, how do you confirm a fix, how do new features get checked before launch. Reviewers are gauging whether accessibility is a practice or a one-time performance.
After the review ends
The review isn't the finish line — it's a checkpoint. Whatever findings come back need a real remediation plan attached, with owners and dates, not a backlog item that quietly ages for two quarters.
Re-test everything that gets fixed against the same conditions the reviewer used, not just a quick visual check. And build whatever the review just taught you back into how new features get built, so the next review starts from a stronger baseline instead of the same one.
The short version
Start eight weeks out, not one. Know who owns what before anyone asks. Check that things work, not just that they exist. Rehearse the real path, not a curated one. And treat the findings afterward as a plan, not a punishment.
None of this guarantees a perfect review. It does mean walking in knowing where you stand, which is the difference between a review that confirms progress and one that discovers problems for the first time in front of an audience.