← Back to Blog

What is WCAG? Plain-English Guide to Web Accessibility (2026)

By Morgan•Published July 14, 2026•22 min read

# What is WCAG? A Plain-English Guide to Web Accessibility (2026)

WCAG (Web Content Accessibility Guidelines) is the global standard for digital accessibility, published by the World Wide Web Consortium (W3C). The current version is WCAG 2.2, and most teams target conformance level AA. The guidelines are built on four principles — Perceivable, Operable, Understandable, and Robust — which together cover how people with disabilities use the web.

If you build websites or apps in 2026, the word "WCAG" is going to come up. It will come up in design reviews. It will come up in vendor security questionnaires. And, increasingly, it will come up in legal letters. ADA Title III lawsuits have set new records year after year, the European Accessibility Act (EAA) became enforceable on June 28, 2025, and the U.S. Department of Justice has finalized a rule under ADA Title II that points state and local governments straight at WCAG 2.1 Level AA.

So this is the primer. What WCAG actually is, who has to follow it, what the levels and principles mean, and where to start if you only have an afternoon. No legalese, no jargon, just the parts that matter for shipping accessible work.

On this page

The 4-step afternoon plan

If you have one afternoon and want maximum impact before reading the rest of this guide, do these four things in order. Each step on its own moves the needle; together they fix most of what an automated tool would flag in a real audit.

  1. Run axe DevTools on your three highest-traffic pages. Note every contrast and label failure.
  2. Fix every contrast failure with our color contrast checker. This alone clears the single most common WCAG violation on the web.
  3. Tab through each page with the keyboard. Note any traps, dead ends, or invisible focus rings.
  4. Audit alt text on the homepage and main product pages — see image alt text for what good looks like.

That alone moves you a long way toward AA. The rest of this article gives you the why, the framework, and the deeper testing playbook so the work compounds instead of becoming busywork.

A short history of WCAG

The web's accessibility standard is older than most of the frameworks you use day to day. Here is the rough timeline:

  • WCAG 1.0 (1999) — the original guidelines. Heavily focused on HTML, written before single-page apps existed.
  • WCAG 2.0 (2008) — the rewrite that introduced the POUR principles and the A/AA/AAA conformance model. Still cited in many laws.
  • WCAG 2.1 (2018) — added 17 new criteria covering mobile, low vision, and cognitive disabilities.
  • WCAG 2.2 (2023) — published in October 2023. Adds 9 new criteria (focus appearance, dragging movements, target size, and more).
  • WCAG 3.0 (in development) — a complete rethink with a scoring model instead of pass/fail. Still a working draft, no firm release date.

The W3C is the standards body. Inside the W3C, the Web Accessibility Initiative (WAI) does the actual writing. Both governments and private companies cite WCAG by version number, so "WCAG 2.1 AA" and "WCAG 2.2 AA" mean different (though similar) things in a contract.

Who WCAG applies to

Government, retail, school, and healthcare icons orbiting a globe, showing the wide reach of WCAG accessibility rules
Government, retail, school, and healthcare icons orbiting a globe, showing the wide reach of WCAG accessibility rules

Short answer: in 2026, WCAG applies to a lot more sites than it used to. The reach depends on where you operate and who your users are.

Government and public sector

In the United States, Section 508 of the Rehabilitation Act requires federal agencies and their contractors to meet WCAG 2.0 Level AA. The 2024 ADA Title II rule extends similar requirements to state and local governments by 2026 or 2027, depending on size. Public universities are covered under Section 504 of the Rehabilitation Act.

In the European Union, public sector bodies have been subject to the Web Accessibility Directive since 2018. That directive points to WCAG 2.1 AA via the EN 301 549 harmonized standard.

Public-facing commercial sites (ADA Title III)

This is the big one for businesses. ADA Title III covers "places of public accommodation," and U.S. courts have ruled that this includes websites with a clear nexus to a physical business — and increasingly, websites on their own.

ADA Title III web-accessibility lawsuits run in the thousands of federal filings every year, with retail, food service, and entertainment consistently leading the pack — see the latest Seyfarth ADA Title III filings tracker for the current count. Most settlements require WCAG 2.1 AA conformance with annual audits.

European Accessibility Act (EAA)

The EAA went into force on June 28, 2025. It applies to private companies selling certain products and services to EU consumers — e-commerce, banking, e-books, transport ticketing, telecoms, and more. Even if you are based outside the EU, if you sell to EU consumers, you are likely in scope. The technical baseline is WCAG 2.1 AA.

Education and healthcare

Section 504 of the Rehabilitation Act and Title II of the ADA pull most U.S. schools and universities in. Healthcare providers receiving federal funding (basically all of them) are covered by Section 1557 of the Affordable Care Act, which has been read to require WCAG conformance for patient-facing tools.

Voluntary adoption

Plenty of private companies follow WCAG even when not strictly required. Reasons range from procurement (enterprise customers ask for VPATs), to talent (accessibility-minded designers want to work somewhere that takes it seriously), to plain good design — accessible products tend to be clearer for everyone.

The 4 POUR principles

Four colorful icons in a 2x2 grid representing the WCAG POUR principles: Perceivable, Operable, Understandable, Robust
Four colorful icons in a 2x2 grid representing the WCAG POUR principles: Perceivable, Operable, Understandable, Robust

Every WCAG success criterion sits under one of four principles. The acronym is POUR, and once you know it, the rest of the standard makes a lot more sense.

Perceivable

Content has to be presentable to users in ways they can perceive. If a user cannot see, hear, or otherwise sense the content, nothing else matters.

This principle covers alternative text for images, captions and transcripts for video, color contrast, and content that adapts to assistive tech. It does not mean every user must be able to use every sense — it means there is always at least one way to perceive the content.

Two example success criteria:

  • 1.1.1 Non-text Content (Level A) — every image, icon, and chart has a text alternative. We dig into this in our image alt text guide.
  • 1.4.3 Contrast (Minimum) (Level AA) — text needs a contrast ratio of at least 4.5:1 against its background (3:1 for large text). For the deep dive, see color contrast and WCAG.

Operable

Users have to be able to operate the interface. The keyboard, the mouse, touch, voice — whichever they use, the page has to respond.

This is where keyboard navigation lives. It is also where you find rules about giving users enough time, avoiding seizure-inducing flashes, and helping people find their way around with skip links and clear focus rings.

Two example success criteria:

  • 2.1.1 Keyboard (Level A) — all functionality must work from a keyboard alone, no mouse required.
  • 2.4.7 Focus Visible (Level AA) — when an element gets keyboard focus, the focus state must be visible. Removing default focus rings without replacing them is a classic violation.

Understandable

Content and the interface must be understandable. That covers readable text, predictable navigation, and helpful error messages on forms.

Understandable does not mean dumbed down. It means consistent — buttons that look like buttons, labels that say what they do, and forms that explain what went wrong instead of just turning red.

Two example success criteria:

  • 3.1.1 Language of Page (Level A) — set a lang attribute on the element so screen readers pronounce content correctly.
  • 3.3.2 Labels or Instructions (Level A) — every form field needs a visible label or clear instructions, not just placeholder text.

Robust

Content must work across user agents — current browsers, current screen readers, and the assistive tech of five years from now. In practice, this is the principle that says "use semantic HTML and valid ARIA."

If you build a custom dropdown out of

tags with click handlers and skip the keyboard and ARIA roles, you fail this principle. Robust is also why screen reader teams care so much about clean markup.

Two example success criteria:

  • 4.1.2 Name, Role, Value (Level A) — every interactive element exposes a name, a role, and any state to assistive tech. Custom components must do this through ARIA.
  • 4.1.3 Status Messages (Level AA) — toast notifications, form validation, and other status updates must be announced to screen readers without changing focus.

WCAG levels: A, AA, AAA

Three rising steps on a podium representing WCAG conformance levels A, AA, and AAA, with badges floating above each step
Three rising steps on a podium representing WCAG conformance levels A, AA, and AAA, with badges floating above each step

WCAG has three conformance levels. Each one is a higher bar, and each higher bar includes everything below it. In WCAG 2.2, the criteria break down like this:

LevelCriteriaWhat it means
A30The minimum. Failing any of these makes content unusable for some people.
AA50 (cumulative)The industry standard and the level most laws require.
AAA28 (cumulative 78)Enhanced accessibility. Not all content can meet this.

Level A — the floor

Level A criteria are baseline. They cover things like "images have alt text," "video has captions," "the page works without a mouse," and "you do not use color alone to convey information." If you fail Level A, real users are locked out.

You should consider Level A the absolute minimum. No serious organization claims Level A as their target — it is what you meet on the way to AA.

Level AA — the standard

Level AA is the level cited in ADA settlements, the EAA, Section 508, and most procurement contracts. When someone says a site is "WCAG-compliant," they almost always mean AA.

AA adds tighter contrast requirements, captions for live video, focus indicators, consistent navigation, and resizing without loss of content. It is achievable for nearly all content, and meeting it gets you most of the way to genuine accessibility.

Level AAA — the ceiling

AAA is the gold standard. It includes things like 7:1 contrast for normal text, sign language interpretation for prerecorded video, and reading level no higher than lower secondary education.

W3C explicitly says you should not target full AAA conformance for entire sites, because some criteria simply cannot be met by some content. Instead, teams aim for "AA + some AAA where it matters" — for example, AAA contrast on safety-critical interfaces, or AAA reading level on government information pages.

When someone tells you their site is "WCAG AA compliant," that is the right answer 95 percent of the time. AAA claims should make you ask follow-up questions.

ScreenSnap Pro
Sponsored by the makers

Tired of plain screenshots? Try ScreenSnap Pro.

Beautiful backgrounds, pro annotations, GIF recording, and instant cloud sharing — all in one app. Pay $39 once, own it forever.

See what it does

The most-violated WCAG criteria

Grid of common web accessibility violations: low contrast text, missing alt text, broken keyboard, unlabeled form, hidden focus ring, and generic links
Grid of common web accessibility violations: low contrast text, missing alt text, broken keyboard, unlabeled form, hidden focus ring, and generic links

WebAIM publishes an annual analysis of the top one million homepages. The same handful of issues come up year after year. If you fix these, you have done most of the work.

1. Low color contrast (1.4.3)

The single most common WCAG failure. WebAIM's annual Million analysis consistently finds low-contrast text on around 80% of homepages. That ratio has barely moved in years.

The rule itself is simple. Normal text needs a 4.5:1 contrast ratio against its background. Large text (24px or 18.66px bold and up) needs 3:1. Logos and incidental decoration are exempt.

The trouble is that designers love light gray on white. It feels modern. It also fails AA in seconds. Run any link, body text, or muted helper copy through our free color contrast checker, or read the longer explainer at color contrast and WCAG for ratios, formulas, and worked fixes.

2. Missing alt text (1.1.1)

The second-most-common failure: images without alt attributes, or with placeholder values like alt="image" or alt="picture". Both are barriers — the first leaves screen reader users guessing, the second wastes their time with noise.

Useful alt text describes the image's purpose, not just its contents. Decorative images get alt="" (empty, but the attribute is there). For everything else, our image alt text guide walks through the rules.

3. Form labels missing or wrong (1.3.1, 3.3.2)

Forms break under WCAG when fields lack visible labels, when labels are not programmatically connected to inputs, or when placeholder text is used as a label. Once the placeholder disappears on focus, screen reader users have no way to know what the field is for.

The fix is one HTML attribute: paired with . Or wrap the input inside the label. Both work.

4. Keyboard inaccessibility (2.1.1)

Custom components built with

and click handlers — modals, menus, tabs, sliders — almost always fail keyboard access. Tab into them, and nothing happens. Tab past them, and you are trapped.

The pragmatic fix is to use real elements: