Skip to content
Website Technology

WCAG Explained: The Standard Behind Accessibility Checklists

WCAG is the standard most accessibility checklists, contracts and laws point to. Here is how it is organised, what Level AA usually asks of a business site, and why tools alone cannot test it.

Electronics and wiring on a workbench
9 sections · 6 min read
In this article · 9 sections

Someone has told you your website should “meet WCAG AA”. Maybe it was a client in Europe, a procurement form, a developer quoting for a redesign, or an accessibility plugin’s sales page. The phrase gets used as if everyone knows what it means, and most business owners quietly do not.

This post explains the standard itself: who writes it, how it is organised, what the levels mean, and what “AA” usually asks of an ordinary business site. If you want the practical list of things to check on your own pages, that is in our website accessibility checklist. This is the background that makes the checklist make sense.

What WCAG is and who writes it

WCAG stands for Web Content Accessibility Guidelines. It is published by the World Wide Web Consortium (W3C), the body that also develops the core standards the web runs on, through its Web Accessibility Initiative. The official overview lives on the W3C’s WCAG page.

WCAG is not a law. It is a technical standard. But laws and contracts in many countries point to it, either directly or through other standards built on it, which is why it shows up in legal conversations. When a regulator, a public-sector buyer or a large customer asks whether your site is accessible, WCAG is usually the yardstick they have in mind.

It is also deliberately technology-neutral. It describes outcomes, such as “a person can operate this with a keyboard”, and leaves the method to whoever builds the site.

The four principles: POUR

Everything in WCAG hangs off four principles, usually remembered as POUR.

  • Perceivable. People must be able to take in the content with the senses they have. Images need text alternatives, videos need captions, and text needs enough contrast to be read.
  • Operable. People must be able to use the controls. Everything should work with a keyboard, nothing should flash in a way that could trigger seizures, and people should have enough time to finish a task.
  • Understandable. The content and the interface should make sense. Pages declare their language, forms explain what they need, and error messages say what went wrong and how to fix it.
  • Robust. It is about code that holds up: the site should be built cleanly enough that browsers and assistive technology, such as screen readers, can interpret it reliably.

Under each principle sit guidelines, and under each guideline sit the parts that actually get tested: success criteria.

Success criteria, in plain words

A success criterion is a single testable statement. Either your page meets it or it does not. Each one has a number, such as 1.1.1 or 2.4.7, and a short name. The numbering simply tells you where it sits: the first digit is the principle, the second is the guideline, the third is the criterion.

A few examples, translated out of standards language:

  • Non-text content (1.1.1): images, icons and other non-text content have a text alternative, unless they are purely decorative.
  • Contrast minimum (1.4.3): normal body text has a contrast ratio of at least 4.5:1 against its background, with a lower bar for large text.
  • Keyboard (2.1.1): everything you can do with a mouse, you can also do with a keyboard.
  • Focus visible (2.4.7): when you tab through a page, you can see where you are.
  • Labels or instructions (3.3.2): form fields tell people what to enter.

Each criterion has W3C “Understanding” and “Techniques” pages explaining its intent and known ways to pass. They are the best place to settle an argument about what a criterion really requires.

Levels A, AA and AAA

Every success criterion is assigned a level.

  • Level A is the minimum. Failing these usually means some people cannot use the content at all, for example a form that cannot be submitted without a mouse.
  • Level AA adds criteria that remove the most common serious barriers, such as low contrast, missing visible focus and inconsistent navigation.
  • Level AAA is the highest and strictest level, including things like much higher contrast and sign language for pre-recorded video.

The levels are cumulative. To claim AA, a page must meet every A criterion and every AA criterion. The W3C itself says AAA is not recommended as a general target for entire sites, because some content simply cannot meet all of it. You can still adopt individual AAA criteria where they make sense.

In practice, when a contract, a policy or a law refers to WCAG, it almost always means Level AA.

Versions: 2.0, 2.1 and 2.2

WCAG has been updated over time. Version 2.0 set up the structure described above. Version 2.1 added criteria aimed mostly at mobile use, low vision and cognitive accessibility, such as content that reflows on a narrow screen without sideways scrolling. Version 2.2 is the current W3C recommendation and adds more, including focus that is not hidden behind sticky headers, minimum sizes for click and tap targets, alternatives to dragging, and login steps that do not depend on memorising or transcribing things.

The versions are designed to build on each other, so a site that meets 2.2 will generally meet the earlier versions too. One criterion about code parsing was removed in 2.2 because modern browsers made it obsolete.

You may also hear about WCAG 3. It is a separate, much larger rework that is still in draft at the W3C. It is not a standard you can be measured against yet, so for now the 2.x series is what matters.

When someone asks for “WCAG AA”, it is worth asking which version. Many existing policies still name 2.1. Building to 2.2 AA covers both.

What AA usually means for a business website

For a typical small business site, meaning a WordPress theme, a few service pages, a contact form and perhaps a shop, most AA work falls into a short set of areas:

  • Text alternatives on meaningful images, and decorative images marked so screen readers skip them.
  • Readable colour contrast for text and for things like form borders and icon buttons.
  • A logical heading structure and link text that makes sense on its own.
  • Full keyboard access to menus, sliders, pop-ups, cookie banners and checkout, with a visible focus indicator.
  • Forms with proper labels, clear error messages and no reliance on colour alone.
  • Captions on video, and pages that still work when zoomed or viewed on a narrow screen.

The hard parts are rarely the content. They are usually theme and plugin components: a mega menu that only opens on hover, a slider with no pause button, a booking widget that traps keyboard focus, or a cookie banner a screen reader cannot dismiss. Those take developer time to fix or replace.

Automated tools versus manual testing

Automated checkers, including free browser extensions and the accessibility section of Google Lighthouse, are genuinely useful. They are quick and consistent at spotting mechanical problems: missing alt attributes, contrast failures, empty buttons, form fields with no label.

What they cannot do is judge meaning. A tool can see that an image has alt text, but not whether “IMG_2041” describes it. It can see a heading tag, but not whether the headings form a sensible outline. It usually cannot tell whether a menu is usable by keyboard, or whether a screen reader announces a checkout error.

So a real WCAG assessment combines both: an automated scan to clear the obvious issues, then a person working through key pages and tasks with a keyboard and a screen reader, checking each relevant criterion. A clean automated score on its own does not mean a site conforms. Be wary, too, of overlay widgets that promise compliance in one line of code; they sit on top of the problems rather than fixing them.

Where this matters legally

Many accessibility laws and procurement rules lean on WCAG. One that affects Indian businesses with European customers is covered in our post on the European Accessibility Act for Indian businesses. Accessibility is also one of the pieces in our overview of what a business website needs now.

If you want a second pair of eyes

We do not sell a fixed accessibility audit package. If you have been asked to meet WCAG AA, or you simply want to know how far your WordPress site is from it, tell us what you need and we will look at the site and tell you honestly what it would involve.

Next in this series: European Accessibility Act for Indian Businesses

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.