What WCAG Means and Why Your Web Developer's Checklist Isn't Enough
WCAG is the international standard for web accessibility, but knowing what the acronym stands for and understanding what compliance actually requires are two different things. Here's what business owners need to understand.
When a business owner asks their web developer whether the site is accessible, the answer is almost always yes. Sometimes it’s accompanied by a screenshot of an automated scan showing zero critical errors.
That answer isn’t necessarily wrong. It’s almost certainly incomplete.
Understanding why requires knowing what WCAG actually is, and what it can and cannot tell you about whether your site serves the people who need it to.
WCAG Is a Standard, Not a Test
The Web Content Accessibility Guidelines, WCAG, are a set of technical criteria developed by the World Wide Web Consortium (W3C) to define what accessible web content looks like. The current standard, WCAG 2.2, is the version referenced by most U.S. accessibility frameworks and by the European Accessibility Act.
WCAG is organized into four principles. Perceivable, Operable, Understandable, Robust, and within those principles, a tiered system of criteria: Level A (minimum requirements), Level AA (the standard most legal and regulatory frameworks require), and Level AAA (enhanced, typically reserved for specific contexts).
WCAG 2.2 AA is the target for most compliance contexts. It includes sixty-six success criteria across the four principles.
The guidelines are technical, specific, and, in some areas, genuinely complex. They cover keyboard navigation, color contrast ratios, text alternatives for images, form labeling, focus indicators, timing of dynamic content, and dozens of other dimensions. Meeting all of them requires deliberate attention at multiple stages of design and development.
What Automated Scanning Actually Covers
Automated accessibility scanning tools (the kind built into browser extensions, CMS audits, and developer workflows) are useful. They’re also limited in a specific and important way: they can only evaluate what a machine can measure.
Automated tools catch roughly 30 to 40 percent of WCAG 2.2 AA issues. The rest require human judgment.
The criteria that automation can evaluate are things like: whether images have alt text present (not whether the alt text is accurate or useful), whether color contrast ratios meet the threshold on static content (not in all states and contexts), whether form inputs have a label element attached (not whether the label conveys enough information to a screen reader user to complete the form correctly).
The criteria that require human judgment include: whether the keyboard navigation order is logical and predictable, whether dynamic content updates are announced appropriately to assistive technology, whether error messages on forms are specific and actionable, whether the reading order in screen reader output matches the visual layout, whether complex interactive elements like modals and accordions behave correctly when navigated by keyboard alone.
A developer who ran an automated scan and saw no critical errors may have a site that passes 40 percent of the standard. The remaining 60 percent requires human evaluation.
Why “We Build to WCAG Standards” Needs a Follow-Up Question
Developers who build accessibly are genuinely valuable. But the phrase “we build to WCAG standards” varies widely in what it means in practice.
For some developers, it means they use semantic HTML, add alt text to images, and run an automated checker before launch. For others, it means they conduct manual keyboard testing, test with real assistive technology, review color contrast across all interactive states, and produce a documented accessibility conformance report.
Both developers might use the same phrase. The outcomes for a user with a visual impairment, motor limitation, or cognitive accessibility need are not the same.
The follow-up questions worth asking a developer or agency: What manual testing steps are part of your process? Do you test with screen readers, and which ones? Can you produce documentation of what criteria were tested and how? What was your most recent finding from a manual keyboard navigation review?
The answers locate where the process actually is, rather than where the language suggests it might be.
The Business Risk That Follows
For business owners, this distinction matters beyond technical completeness. The legal standard in U.S. courts for ADA Title III compliance in digital contexts has increasingly referenced WCAG 2.2 AA as the benchmark. An automated-only audit doesn’t constitute a documented good-faith effort to meet that standard.
More practically: a site that passes automated scans but fails on keyboard navigation, screen reader compatibility, or form accessibility excludes real users. The ADA’s concern is not technical documentation, it’s whether people with disabilities can access the service. A site that cannot be navigated by keyboard alone excludes users with motor disabilities. A site whose forms are unlabeled for screen readers excludes users who are blind. Those exclusions represent both a legal exposure and a business consequence, regardless of what the automated scan reported.
What a Complete Evaluation Actually Looks Like
A full accessibility evaluation of a website typically combines automated scanning with manual review against WCAG 2.2 AA criteria. The manual review covers keyboard navigation across all interactive elements, screen reader behavior using at least two common tools (typically NVDA or JAWS on Windows, VoiceOver on Mac/iOS), color contrast across all states including hover and focus, form and error handling, and document structure and reading order.
The output is not a binary pass or fail. It’s a documented inventory of what was tested, what was found, what the severity is, and what remediation is required. That inventory is what makes the evaluation actionable, and what provides the documented baseline that matters if a legal question ever arises. The COREaccess™ Accessibility Leadership System covers the full framework — audit, remediate, train, and monitor — for organizations that need documented, standards-based conformance.
The Small Business Owner’s Guide to Website Accessibility covers accessibility compliance for small businesses, including where legal obligations come from and what a realistic compliance path looks like. If you want to know where your site actually stands against the full WCAG 2.2 AA standard, not just what the automated scan found, a 15-minute conversation is a reasonable starting point.