"We're Basically Compliant"
A startup founder is prepping for a board meeting and someone asks, offhand, "are we accessible?" Nobody's sure. So the founder does what anyone would do: googles "how do I know if my site is accessible," installs a free browser extension, and runs it against the homepage.
Thirty seconds later, a green checkmark appears. Zero errors. The founder screenshots it, drops it in Slack, and tells the team: "We're basically compliant."
Here's the problem. That scanner just checked the kind of thing a computer can check by reading code patterns — missing alt attributes, missing form labels, obvious contrast failures. It didn't touch the checkout flow. It didn't try navigating the site with a keyboard. It has no idea whether the alt text that is there actually describes anything useful, or whether a screen reader user could complete a purchase without getting stuck in a dead end.
Industry estimates commonly put automated-tool coverage at roughly 30-40% of total WCAG success criteria. That green checkmark wasn't wrong, exactly. It was just answering a much smaller question than "are we accessible?"
This is the gap that turns into a demand letter six months later. So let's fix it — with an actual process, not a browser extension and a hope.
Why One Scan Was Never Going to Be Enough
A real WCAG audit works in three layers, and each one catches failures the other two structurally cannot see.
Automated scanning — tools like axe DevTools, WAVE, Lighthouse's accessibility audit, or axe-core wired into CI — is fast, cheap to run repeatedly, and excellent at catching objectively-detectable issues: missing alt attributes, missing form labels, insufficient color contrast, a missing document language attribute, duplicate IDs. If a rule can be expressed as "does this code pattern exist or not," a scanner can check it at scale, forever, for free. That makes it genuinely valuable as a first pass and as a regression net in continuous integration.
But a scanner can only evaluate what's programmatically detectable. It cannot judge meaning. It cannot tell you whether an alt attribute exists — but it also cannot tell you whether that alt text says "image47.jpg" or actually describes the chart it's attached to.
Manual review is where a human looks at the things code-pattern scanning structurally can't judge: whether alt text is actually meaningful, whether the heading structure reflects a logical document outline (not just headings that exist, but headings that make sense in order), whether ARIA roles and labels genuinely match what the element visually does, whether focus order tracks the visual reading order, and whether an error message actually helps a user fix the problem instead of just announcing that one exists.
Assistive technology testing — real screen reader and keyboard-only testing — is the layer that catches experience-level failures. This is the one teams skip most often, and it's the one that matters most, because a page can pass every automated check and still be genuinely confusing or broken when a screen reader user actually tries to move through it. A modal that traps focus. A "skip to content" link that goes nowhere. A form that submits silently with no announced confirmation. None of that shows up as a red X in a scanner. All of it shows up in five minutes of real keyboard navigation.
Skip any one of these three layers and you haven't done a partial audit — you've done a different, smaller task and called it the whole thing.
The Tiered Checklist
Not every WCAG success criterion carries equal weight in practice. Some represent the highest combination of legal exposure and real usability breakage; others matter but rarely make or break a case or a user's ability to complete a task. Work through the tiers in order.
Tier 1 — Highest legal and usability risk
- Keyboard operability, no keyboard traps (2.1.1, 2.1.2) — every interactive element reachable and operable via keyboard alone, and no component that traps focus once entered.
- Visible focus indicators (2.4.7) — a keyboard user can always see, at a glance, where focus currently sits.
- Form labels and error identification (3.3.1, 3.3.2, 4.1.2) — every input has a programmatically associated label, and errors are identified in a way assistive technology can announce.
- Alt text on meaningful images (1.1.1) — present, and actually descriptive of the image's purpose in context.
- Color contrast for text and UI components (1.4.3, 1.4.11) — the 4.5:1 text minimum and the 3:1 non-text minimum for borders, icons, and controls.
Tier 2 — Structural and content clarity
- Heading structure and landmarks (1.3.1) — headings form a logical outline; landmarks (nav, main, footer) are correctly marked up.
- Link purpose clarity (2.4.4) — link text makes sense on its own, not a page full of "click here."
- Captions on video (1.2.2) — accurate, synced captions on any video content.
- Reflow at mobile widths (1.4.10) — content reflows without loss of information or horizontal scrolling at narrow viewports.
Tier 3 — Newer and enhanced criteria
- WCAG 2.2 additions — target size for touch controls (2.5.8), redundant entry (3.3.7, don't make users re-enter information they already provided), accessible authentication (3.3.8, no cognitive-function tests as the only login method).
- AAA-level enhancements where genuinely feasible, applied selectively rather than as a blanket requirement.
Run the tiers in order, not because Tier 2 and 3 issues don't matter, but because Tier 1 failures are the ones most likely to block a task entirely or trigger legal exposure. Fix the doors before you polish the hallway.
Scope: Don't Just Audit the Homepage
Here's a mistake that quietly undermines an otherwise well-run audit: checking one page and generalizing. A homepage built by your best designer, reviewed by the most people, and touched the most recently is almost always your most accessible page — and therefore the worst page to use as your sample of one.
A full audit should sample templates and page types, not just the entry point:
- The marketing homepage
- A product or detail page
- A search results page
- A form or checkout flow — arguably the highest-stakes page type, since it's where a failure blocks a transaction rather than just a read
- Any PDF documents linked from the site
- Any embedded third-party widget — chat, payment processor, video player
That last one deserves its own mention. Third-party embeds frequently introduce their own accessibility failures that the parent site doesn't directly control. A chat widget with an unlabeled button, an embedded payment iframe with no keyboard support, a video player whose controls a screen reader can't reach — these ship inside someone else's code, land on your page, and become your liability anyway. An audit that only checks first-party templates will miss them entirely.
The Audit Is a Snapshot, Not a Finish Line
This is the part that's easy to forget the moment the audit report is filed away: it describes the site as it existed on the day it was tested. It doesn't describe the site after next week's content update, next month's new landing page, or next quarter's redesigned checkout flow.
A site that passes today can regress with a single unreviewed change — a new form field added without a label, a marketing team pasting in a low-contrast promotional banner, a developer adding a modal without testing it against a keyboard. None of that requires bad intent. It just requires the absence of an ongoing check.
That's why ongoing monitoring, not a one-time audit, is what actually sustains compliance over time. Think of the audit as the baseline measurement and the starting point — not the deliverable that ends the conversation.
The Confident Version
A green checkmark from a free browser extension tells you something real, but it tells you roughly a third of the story. The other two-thirds — whether your content genuinely makes sense to a screen reader, whether a keyboard user can actually complete your checkout flow, whether your alt text describes anything at all — only shows up when automated scanning is paired with manual review and real assistive technology testing, run across your actual page types, including the third-party widgets you didn't build.
Run it in that order — automated first pass, manual review, assistive tech testing, sampled across templates — and you get an audit that holds up against both real users and a legal challenge. Run only the first layer, and you get a screenshot for a Slack channel.
WCAG.World runs full three-layer audits — automated, manual, and assistive-technology testing — across your real page templates, not just the homepage. See pricing and get a proper audit started before the next content update quietly breaks what today's green checkmark said was fine.