WAI is the branch of the W3C that develops accessibility standards and guidance. WCAG comes from it, and so does the ARIA specification, which is why you see "WAI-ARIA" written out. Those two come from different working groups inside the same initiative, so they are maintained on separate schedules and can sit slightly out of step on a detail. ARIA is a W3C Recommendation, the same document status as WCAG itself, which does not oblige anybody to use ARIA. What it means is that once you do, its requirements govern how. The techniques, the Understanding pages and the tutorials are WAI's too, and those are informative, meaning they explain how to pass rather than adding anything you have to pass.
In practice
WCAG is one of three standards rather than the whole model, and the other two explain why an author cannot fix everything alone. One covers authoring tools, meaning the content management systems, page builders and editors people publish through, and it says the tool should be accessible to use and should help you produce accessible output. Another covers user agents, meaning browsers and media players. A site can be built perfectly and still be unusable through a bad browser, or produced by a tool that cannot emit the markup you need.
The authoring tool standard is the one most owners have never heard of and most owners are affected by. If you publish through WordPress, Shopify, Webflow or Squarespace, that is the standard describing what the tool owes you. It is a reasonable thing to raise with a vendor who keeps telling you accessibility is your problem.
It is also the source of things people cite without knowing where they came from. The accessibility statement generator, the Easy Checks guide, and the ARIA Authoring Practices Guide. That last one is informative and is not ARIA, which is a distinction people conflate constantly, including in audit reports.
WAI defines the vocabulary the field uses, which is why a good report and a good glossary agree on what the words mean. Screen reader, text-to-speech, speech recognition and the rest all have careful definitions in its material, and they are more precise than the way most of us say them out loud.
Why it matters
A great many of the accessibility claims you will be handed trace back to a WAI document, and all of those are free, which means anything a vendor tells you about the standard can be checked against the source rather than against their summary. One sentence from that material is worth having on hand by itself. No tool alone can determine whether a site meets accessibility standards, and knowledgeable human evaluation is required. That is the body that wrote the standard, saying so about its own standard, and it settles most conversations about a green score.
The standard nobody mentions
If your content management system makes it impossible to add alt text, or its editor produces headings that turn out to be bold text, the tool is part of the problem even though the published page is still yours to answer for. There is a separate W3C standard for authoring tools saying the tool should be accessible to use and should help you produce accessible output. It is the one to name in a support ticket.
Where this shows up on the site
Related terms
- W3CThe W3C is the international non-profit that publishes the web's standards, including CSS and, through its Web Accessibility Initiative, WCAG.
- WCAGWCAG is the international standard for web accessibility, published by the W3C.
- ARIAARIA is a set of attributes that tell assistive technology what a custom control is and what state it is in.
- TechniqueA technique is one of the W3C's documented ways of meeting, or of failing, a WCAG rule.
Knowing the word is the easy part.
Find out where your own site stands. The free scan checks 10 pages in a real browser against all 90 supported automated rules, separates 27 best-practice checks from its WCAG findings, and names the rule behind every result.