A plain-English primer for website owners who just received an automated accessibility audit and want to understand what the report is actually telling them.
WCAG stands for Web Content Accessibility Guidelines. It is the international standard for making websites usable by people with disabilities. The standard is maintained by the World Wide Web Consortium (W3C), the same body that maintains HTML and CSS.
The version your audit tests against is WCAG 2.1, published in 2018. A newer version (WCAG 2.2) was published in 2023 and adds 9 new success criteria; it does not remove or contradict anything in 2.1. WCAG 2.1 is the version most legal frameworks (in the US, the European Union, Canada, Australia, and elsewhere) currently reference.
WCAG defines about 78 testable rules called success criteria. Your audit tests the 50 of them that are at Level A and Level AA, which together represent the standard most legal requirements expect.
Roughly 1 in 5 adults lives with a disability that can affect how they use the web. That includes people with low vision, blindness, deafness, motor impairments, and cognitive differences. An accessible site means more of them can become customers, members, students, or readers without friction.
Beyond the human case, there is a legal case. Multiple jurisdictions explicitly reference WCAG as the conformance bar:
There is also a usability case that has nothing to do with disability: many WCAG techniques (semantic markup, keyboard support, sensible color contrast, alt text on images) make sites work better on mobile, on flaky connections, and for search engines.
WCAG groups its success criteria under 4 high-level principles, often abbreviated POUR: Perceivable, Operable, Understandable, Robust. Every criterion lives under exactly one principle.
Users must be able to perceive the information on the page. If you put information in an image, also put it in text. If you put information in audio, also offer a transcript. Color alone cannot carry meaning. Text needs enough contrast to read.
Users must be able to operate the interface. Every interactive element works with a keyboard alone, no mouse required. Time limits can be adjusted. Auto-playing media can be paused. Navigation is consistent across pages.
Users must be able to understand both the content and the interface. The page declares its language. Form fields have clear labels and helpful error messages. Navigation behaves predictably; form fields do not jump the user to a new page just because they typed in them.
Content must be robust enough to work with a wide range of assistive technology, today and as the technology evolves. Use real semantic HTML elements (headings, buttons, lists, form labels) rather than re-implementing them with generic div and span tags. When custom widgets are needed, mark them up with the right ARIA roles, names, and states.
Each WCAG success criterion is assigned one of three conformance levels:
| Level | Meaning | Where it sits in practice |
|---|---|---|
| A | Bare minimum. | Failing a Level A criterion means significant numbers of users will be entirely blocked from using your site. Hitting Level A only is below the modern bar. |
| AA | The industry and legal standard. | Most laws and procurement requirements ask for AA. This is the level your audit tests against. Aiming for AA is a reasonable, achievable target for most sites. |
| AAA | Enhanced. | Some criteria at AAA cannot be met by all content (for example, captioning every live video). The W3C explicitly states that full AAA conformance is not achievable for most sites. Pursue specific AAA criteria where they make sense; do not chase blanket AAA. |
Your audit reports against Level A and Level AA combined. Level A failures are usually the most urgent because they block the most users.
The audit report has two main views.
Use this view when you want to fix a class of problem everywhere it appears. For example, if your report shows criterion 1.1.1 Non-text Content with 40 affected elements across 5 pages, that means the same kind of issue (missing alt text on images) is showing up in many places, and you can probably fix it with one change to a template or component.
Use this view when you want to fix one page at a time, for example if you are about to launch a new product page and want to clean it up specifically.
A reasonable order of attack:
Each violation in the report includes a copy-paste prompt you can paste into Claude or ChatGPT. The prompt gives the model the violation, the offending HTML, and the WCAG criterion, then asks it to ask you which web framework you use before producing fix code. This means you do not need to manually translate generic accessibility advice into your stack; the model does it. The model will also explain the change and suggest how to verify it.
Your audit uses an open-source rule engine called axe-core. axe-core is the industry standard for automated accessibility testing, and it is honest about its limits: it catches roughly 30 to 40 percent of WCAG issues automatically. The remaining 60 to 70 percent need a human.
For these, you need the manual testing described in the next section.
After working through the violations in your audit, do at least these manual checks:
Every criterion your audit can flag is listed here, grouped by principle. Each links to the official W3C explanation. The plain-English description is what the criterion requires; for examples and edge cases, follow the W3C link.