What WCAG Means and Why a Developer's Checklist Is Not Enough
WCAG is the international standard for web accessibility. This post explains what it covers, which version to target, and what automated scans can and cannot show.
Updated with additional research.
When a business owner asks a web developer whether the site is accessible, the answer is often yes. Sometimes it comes with a screenshot of an automated scan showing zero critical errors.
That answer may be correct as far as it goes. It is usually incomplete.
Judging it requires knowing what WCAG is and what it can say about whether a site works for the people who need it.
WCAG Is a Standard, Not a Test
The Web Content Accessibility Guidelines, WCAG, are technical criteria developed by the World Wide Web Consortium (W3C) to define accessible web content. WCAG 2.2 is the current W3C version. WCAG 3.0 is still a working draft and does not replace the 2.x versions.
WCAG is organized around four principles: Perceivable, Operable, Understandable and Robust. Within those, criteria sit at three levels. Level A is the minimum, Level AA is the level that laws and policies most commonly cite, and Level AAA is enhanced and usually applied only in specific contexts. W3C itself says AAA conformance is not recommended as a general policy for entire sites.
By my count from the W3C specification, WCAG 2.2 has 86 success criteria in total. Conforming at Level AA means meeting the 55 criteria at Levels A and AA. They cover keyboard operation, color contrast, text alternatives for images, form labels, focus visibility and timing, among other areas.
Which Version Applies
Laws and policies cite different versions, and they change slowly. Revised Section 508, which governs federal agencies, uses WCAG 2.0 Level AA. The Department of Justice rule for state and local governments under ADA Title II uses WCAG 2.1 Level AA. In Europe, the current version of the harmonised standard EN 301 549 is built on WCAG 2.1 Level AA, and a newer revision based on WCAG 2.2 is pending formal citation.
For private businesses, ADA Title III applies to business websites, according to the DOJ’s 2022 web accessibility guidance. The same guidance says DOJ has no regulation setting detailed technical standards for them, and it points to WCAG as helpful guidance.
The practical result is that WCAG 2.2 Level AA is a sensible target. It is the current version, and a site that conforms to it meets the 2.1 criteria that today’s regulations cite.
What Automated Scanning Covers
Automated scanning tools, such as browser extensions and developer workflow checks, are useful. They have a clear limit: they can only evaluate what a machine can measure.
How much they find depends on what is counted. Deque, an accessibility software vendor, analyzed more than 13,000 page states and about 295,000 issues from its own audits. Automated testing found 57.38% of those issues by volume. The rest needed manual review.
Counting by test, not by volume, gives a lower number. A UK government test of 10 free tools ran against a page built with 143 known failures. The best tool found 41% of them, and 29% were missed by every tool.
A clean scan shows that no automatically detectable failures remain. WebAIM notes that the absence of detected errors does not indicate a page is accessible or conformant. Automation can confirm that an image has alt text, not that the text is useful. It can confirm that a form field has a label, not that the label gives a screen reader user enough to complete the form.
Human judgment is needed for questions such as whether keyboard order is logical, whether dynamic updates are announced to assistive technology, whether error messages are specific, and whether modals and accordions behave when used by keyboard alone.
Why “We Build to WCAG” Needs a Follow-Up Question
Developers who build accessibly are valuable. Though, the phrase “we build to WCAG” covers a wide range of practice.
For some developers it means semantic HTML and an automated check before launch. For others it includes manual keyboard testing, screen reader testing, contrast checks across interactive states and a written conformance report.
Both can use the same words. The outcomes for a user with a visual or motor impairment differ.
Useful follow-up questions include which manual testing steps are part of the process, which screen readers are used, and whether the criteria tested are documented. Another is what the most recent keyboard navigation review found. The answers show where the process stands, which the wording alone does not.
What a Fuller Evaluation Includes
A fuller evaluation combines automated scanning with manual review against WCAG 2.2 Level AA. A thorough manual review covers keyboard navigation across all interactive elements, screen reader behavior in at least two common tools, contrast in hover and focus states, form and error handling, and document structure.
The output is a documented list of what was tested, what was found and how severe each finding is. That list makes the work actionable, and it gives a baseline to measure later changes against.
A site that passes automated scans but fails on keyboard navigation or form labels still excludes people. A site that cannot be used by keyboard alone shuts out users with motor disabilities. Unlabeled form fields shut out users who are blind.
The Small Business Owner’s Guide to Website Accessibility covers where legal obligations come from and what a realistic path looks like for a small business.
If you want to know where your site stands against WCAG 2.2 Level AA, beyond what an automated scan found, a 15-minute conversation is a reasonable starting point.