WCAG

What is WCAG?

WCAG, the Web Content Accessibility Guidelines, is the international technical standard published by the World Wide Web Consortium (W3C) that defines how to make web content accessible to people with disabilities. Web content accessibility guidelines cover text, images, audio, video, and interactive elements, organizing every requirement into testable success criteria at three conformance levels: A, AA, and AAA.

At a glance

Why is WCAG important when it comes to accessibility?

More than 2.5 billion people globally need assistive technology, according to the World Health Organization, which includes the use of assistive technologies to access the web.

This number includes screen reader users who are blind or have low vision, people who navigate a page with a keyboard alone, people with cognitive or learning disabilities who need plain language and a predictable layout, and people with limited hand mobility who can't manage fine mouse movements.

Without a shared set of accessibility guidelines, teams risk fixing only a few accessibility barriers while leaving several others, meaning website visitors have to navigate around content they can't actually use.

WCAG, which is the backbone of most accessibility regulations worldwide, gives everyone who builds or maintains a website – whether they design it, code it, or write for it – a common technical standard to build toward.

The Americans with Disabilities Act doesn't name WCAG directly, since the law predates WCAG 1.0 by a number of years, but courts and regulators treat it as the practical benchmark for what counts as an accessible website.

Government agencies increasingly write WCAG straight into procurement rules and disability act regulations, with the European Accessibility Act referencing it through the technical standard EN 301 549. Following WCAG guidelines is one of the fastest ways to align your accessibility efforts with what regulators already expect, on either side of the Atlantic.

Teams that achieve WCAG compliance also tend to improve usability for people without disabilities – clearer navigation, better contrast, more forgiving forms, and error messages everyone can actually understand. Website accessibility and good design overlap in many ways, and building accessible content from the start usually costs less than retrofitting it later.

Meanwhile, web accessibility lawsuits have increased steadily, and a documented WCAG compliance program is one of the strongest defenses a business has against them.

Accessibility involves more than fixing one issue at a time. Making digital content accessible as you go is a better move than relying a separate audit after the fact.

A screen reader user who can finally hear content read aloud in the right order, or someone with cognitive disabilities who can finally get through a checkout flow without getting stuck, is the real measure of whether that coordination worked.

How WCAG is structured

The WCAG guidelines are written and maintained by the Accessibility Guidelines Working Group, part of the World Wide Web Consortium's Web Accessibility Initiative. The working group develops WCAG through the same open, consensus-based W3C process used for every other web standard, publishing draft versions for public comment before anything becomes a stable, referenceable recommendation.

The POUR principles

Every WCAG guideline sits under one of four principles, often remembered by the acronym POUR: perceivable, operable, understandable, and robust.

• Perceivable covers text alternatives for images and requirements like captions for time-based media.
• Operable covers full keyboard access and enough time to complete tasks, rather than a keyboard trap that leaves someone stuck on a page and unable to operate functionality with just a keyboard.
• Understandable covers plain, simple language and predictable navigation that helps users avoid and correct mistakes.
• Robust covers markup that current and future user agents, including assistive technologies, can reliably interpret.

Under those four principles sit 13 guidelines, covering everything from operable user interface components to perceivable visual content. Then, under each guideline, sit the individual, testable success criteria: the specific, checkable rules that determine whether content actually conforms to WCAG.

To conform with the guidelines, you have to meet the applicable WCAG success criteria at every level you've committed to, rather than just make a general effort to be accessible.

The three conformance levels

Each success criterion is written for one of three conformance levels: A, AA, or AAA.

• Level A covers the accessibility requirements that would otherwise lock people with disabilities out of digital content entirely, like missing text alternatives for images.
• Level AA success criteria add requirements most users notice day-to-day, such as color contrast and consistent navigation across web pages – level AA conformance is what most accessibility standards and WCAG conformance claims are built around.
• Level AAA success criteria push further still, covering things like sign language interpretation for prerecorded video with audio. However, W3C itself doesn't recommend AAA as a general policy target, since not all kinds of content can meet every level AAA conformance requirement.

The latest version of WCAG

The WCAG 2 series – the collection that every current law and standard references – has gone through three iterations so far. WCAG 1.0, published in 1999, has long been superseded.

1. WCAG 2.0, published in 2008, introduced the guideline and success criteria structure still in use today.
2. WCAG 2.1 added a guideline and 17 more success criteria in 2018, aimed largely at mobile accessibility and input methods beyond a mouse.
3. WCAG 2.2 added 9 success criteria on top of that in 2023, covering things like clearer focus indicators and simpler authentication for mobile devices and desktop alike.

Content that meets WCAG 2.2 also meets 2.1 and 2.0, so updating web accessibility policies to reference the newest version doesn't require you to rework pages that already conform to an older one.

A working draft of WCAG 3.0 is underway, but it's years from replacing WCAG 2 as the technical standard governments and businesses rely on.

Understanding WCAG conformance levels as an additive history rather than a series of replacements makes it much easier to prioritize fixes instead of chasing whichever version was mentioned most recently.

A WCAG example

Let’s take success criterion 2.1.2: No Keyboard Trap.

It is a good way to see how a single, testable success criterion works in practice. Success criterion 2.1.2 sits under the operable principle at Level A and exists to make sure a keyboard-only user can always move focus away from any part of a page, including custom widgets like modals and date pickers.

Keyboard traps often show up in custom widgets, while native HTML elements rarely cause this problem on their own.

A modal built without keyboard handling often creates a keyboard trap like this one:

<div class="modal" tabindex="-1">
  <input type="text" placeholder="Search">
  <button>Close</button>
</div>
<script>
document.querySelector('input').focus();
</script>

‍‍Once focus lands inside that modal, a keyboard-only user has no documented way to tab back out. There's no listener for the Escape key, and the close button might not even be reachable if the surrounding script only moves focus forward.

A version that meets the success criterion adds a clear way out:

<div class="modal" role="dialog" aria-modal="true" tabindex="-1">
  <input type="text" placeholder="Search">
  <button id="close">Close</button>
</div>
<script>
const modal = document.querySelector('.modal');
const closeModal = () => modal.remove(); // or your own close logic
modal.querySelector('input').focus();
modal.querySelector('#close').addEventListener('click', closeModal);
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') closeModal();
});
</script>

‍Adding an Escape key handler and a reachable close button satisfies the No Keyboard Trap requirement. The role="dialog" and aria-modal="true" attributes in the markup provide assistive technologies with a reliable way to interpret what the component is, which is just as important as the keyboard fix itself.

WCAG vs. ADA compliance

WCAG and ADA compliance often get used interchangeably, but they aren't the same thing.

The ADA's text doesn't mention WCAG or any technical standard for websites, since Congress passed the law in 1990, well before WCAG existed.

The reality, though, is that courts, settlement agreements, and government agencies all point back to WCAG when they describe what an accessible website looks like, and a defendant's best evidence in an ADA case is almost always proof that its site was built to conform to WCAG at a named version and level, not a general claim of good intent.

That expectation now extends to state and local governments directly – covered in the related question below.

Common mistakes or misconceptions

Here are a few misconceptions about how WCAG works.

• Treating an older WCAG version as outdated. WCAG 2.0, 2.1, and 2.2 are all still valid, current standards. W3C recommends using the newest one, but conforming to an earlier version doesn't mean a site's approach is deprecated.
• Assuming Level AAA is the goal. Level AA is the conformance level named in nearly every law and policy that references WCAG. W3C itself advises against requiring AAA site-wide, since some AAA success criteria can't be satisfied for every type of content.
• Confusing an automated scan with full conformance. Automated tools catch a meaningful share of missing accessibility features, like alt text gaps or contrast failures, but plenty of success criteria, like whether an error message actually reads as understandable, need a human tester behind a keyboard and a screen reader.
• Believing conformance claims are self-certifying. A team can follow WCAG guidelines in good faith and still fail an audit. Conformance claims only hold up when they're backed by real testing against the success criteria, not just a general effort to be accessible.
• Assuming WCAG only covers what's on screen. Several success criteria apply to underlying code, timing, and behavior that a sighted, mouse-using tester would never notice, which is exactly why keyboard-only and screen reader testing catch failures that a purely visual review might miss.