Web Content Accessibility Guidelines (WCAG)

The Web Content Accessibility Guidelines, or WCAG, are an industry-standard set of accessibility requirements for websites, put forth by the World Wide Web Consortium (W3C). WCAG is also often used more broadly as a basis for more generalized digital accessibility requirements.

Owing to its adoption as an industry standard, WCAG also often forms the basis for legal web accessibility requirements in many jurisdictions around the world, and courts often require adherence to WCAG as remediation steps following lawsuits.

The current version of the Web Content Accessibility Guidelines is WCAG 2.2, which became the W3C Recommendation in October 2023. Before that, WCAG 2.1 became the standard in June 2018, supplanting WCAG 2.0, which had been made the standard in December 2008.

Owing to the pacing of legal processes and case law, different versions of WCAG are the standard in different jurisdictions, but at this point, you can be reasonably confident that if a legal requirement points to WCAG, it will point to some 2.x version.

WCAG 3 exists purely as a very early draft version, and is likely many years out still. WCAG 3 is expected to substantially restructure requirements and what it means to meet them.

The Web Content Accessibility Guidelines have a hierarchical structure. They are first divided into overarching principles. Each principle is divided up into guidelines. Guidelines are further broken up to success criteria — the pass/fail requirements most web developers will find themselves working in. Success criteria are grouped up by conformance level, and WCAG helpfully provides some sufficient techniques that could be used as possible ways to meet the requirement.

The Web Content Accessibility Guidelines are broken up into four overarching principles: broad, north-star ideals about what it fundamentally means for web content to be accessible in the first place. These principles are:

1. Perceivable: Information and user interface components must be presentable to users in ways they can perceive.
2. Operable: User interface components and navigation must be operable. (In other words, a disabled person should be able to actually use the interface)
3. Understandable: Information and the operation of the user interface must be understandable. (Not only should disabled people be able to get to content and controls and then use them, doing so should be intuitive and seamless)
4. Robust: Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.

Collectively, these principles are remembered with the mnemonic POUR.

Where WCAG’s principles mark broad, north-star ideals about accessibility, its guidelines make more specific assertions about what a user should actually expect. For instance, while the Principle 2, “Operable,” asserts that disabled people should generally be able to use an interface, Guideline 2.1: Keyboard Accessible asserts that part of making interfaces operable is ensuring that all functionality is usable via the keyboard.

Guideline 2.1’s numbering indicates that it is the first guideline to fall under the second principle (“Operable”).

Guidelines are further broken up into success criteria: the actual pass/fail requirements of WCAG. These are specific, testable assertions about how a webpage should work.

For example, the Guideline 2.1: Keyboard Accessible includes Success Criterion 2.1.2: No Keyboard Trap, which requires that:

If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

This is testable; if in using a page with the keyboard, your keyboard focus gets stuck on a piece of the page with no clear or familiar way out, then the page fails this criterion.

Success Criterion 2.1.2’s numbering marks it as Guideline 2.1’s second success criterion.

As testable, pass/fail requirements, accessibility auditors and automated testing tools will generally point to specific success criteria when surfacing defects on a site.

Each success criterion is assigned a conformance level from among Level A, Level AA, and Level AAA, levels which generally go from most basic/fundamental (“A”) to loftiest (“AAA”).

• Level A conformance entails meeting all Level A criteria.
• Level AA conformance entails meeting all Level A and AA criteria.
• Level AAA conformance entails meeting all success criteria.

The industry standard and most frequent legal standard is Level AA conformance. This means that Level AAA criteria are often treated as nice-to-haves, though it is absolutely worth evaluating whether any Level AAA criteria make sense for your experience or audience.

While success criteria assert binary pass/fail claims about what a given page/site must or must not do, they do not generally prescribe how web contributors should go about meeting the requirement.

That said, the Web Content Accessibility Guidelines documentation does provide informative resources that might be helpful for web contributors trying to address its requirements.

One such resource type is its Understanding documents. Each guideline and success criterion has its own Understanding page, which clarifies the intent behind the requirement, and provides possible ways to test for that requirement. For instance, Success Criterion 2.1.2: No Keyboard Trap’s Understanding document, Understanding No Keyboard Trap, explains whom the requirement is intended to benefit and describes a few examples of web experiences that could satisfy this requirement.

WCAG also lists sufficient techniques — approaches one could use to address a given success criterion. Technique G21 is one such example, providing several mechanisms a site could lean on for ensuring a user’s focus doesn’t get stuck somewhere without recourse, which would result in a Success Criterion 2.1.2: No Keyboard Trap failure. If a web contributor finds a different approach for meeting the criterion, then great! That works, too.

Finally, WCAG lists possible failures, describing certain UX patterns that would violate a given success criterion, with context as to why. For instance, Failure F10 notes that when multiple applets or content formats are mixed and matched, an overreaching plugin could trap the user in a given context with no way out, which would fail Success Criterion 2.1.2: No Keyboard Trap. This isn’t the only way the criterion could fail; just one way that it might.