Website Accessibility and WCAG: What the Guidelines Say

WCAG, the Web Content Accessibility Guidelines, is the W3C's international technical standard for making websites usable by people with disabilities. It sets out testable success criteria, grouped under four principles and graded at three levels: A, AA and AAA. Following WCAG makes a site easier for more people to use, including keyboard users, screen reader users and anyone zooming in on a phone. This explainer is part of our website design best practices guide.

Below, we cover what the guidelines say, how the levels work, what changed in WCAG 2.2 and common issues worth checking on real sites. This guide is general information, not legal advice.

What WCAG is and who writes it

WCAG is written by the Accessibility Guidelines Working Group, part of the World Wide Web Consortium's Web Accessibility Initiative (WAI). Its goal is a single shared standard for web content accessibility that works for people, organizations and governments around the world.

There are three published versions in the WCAG 2 family. WCAG 2.0 came out in December 2008, WCAG 2.1 in June 2018 and WCAG 2.2 in October 2023, with an update in December 2024. Each version keeps the earlier success criteria and adds new ones, so content that meets WCAG 2.2 also meets 2.1 and 2.0. The one exception is 4.1.1 Parsing, which WCAG 2.2 marks as obsolete.

"Content" here means more than text. It includes images, sound, video and the code that defines structure and presentation. The standard is written for the people who build and evaluate sites: designers, developers, content editors and testers. The W3C itself points out that WCAG is a technical standard, not an introduction to accessibility, which is why plain-English guides like this one exist.

The four principles behind WCAG

WCAG 2.2 has 13 guidelines, and every guideline sits under one of four principles. The W3C's wording is that content must be:

1. Perceivable. Information and interface parts must be presentable in ways people can perceive. Text alternatives for images, captions for video and enough colour contrast all live here.
2. Operable. People must be able to operate the interface. Everything must work from a keyboard, there must be enough time to read and act, and nothing should trap focus or flash dangerously.
3. Understandable. People must be able to understand both the information and how the interface works. Pages should declare their language, behave predictably and help people avoid and fix form mistakes.
4. Robust. Content must work reliably with a wide range of browsers and assistive technologies, now and as they change. In practice, this means using standard HTML correctly and giving custom controls a proper name, role and state.

The W3C notes that if any of these fails, some people with disabilities can't use the page at all. WCAG deliberately covers only problems that affect disabled people more severely than others. Many of its fixes, such as clear headings and readable contrast, still make a site easier for everyone.

Conformance levels: A, AA and AAA

Each success criterion has a level. The levels build on one another, so a page can only claim a level if it meets every criterion at that level and below:

Two rules in the standard catch people out. First, conformance applies to full pages, including every responsive version a page shows at different screen sizes. You can't leave out a widget and call the rest of the page conformant. Second, it applies to complete processes. If a contact or booking flow has three steps, all three must meet the level for any of them to count.

WCAG also says that requiring Level AAA as a general policy for entire sites is not recommended, because some content can't meet every AAA criterion.

What changed in WCAG 2.2

WCAG 2.2 added nine success criteria. Most help people with low vision, limited dexterity or cognitive disabilities, and several affect everyday parts of a site, such as sticky headers, buttons, forms and logins:

Common issues worth checking first

Many barriers on business websites come from a short list of problems. These are common issues worth checking first, with the criterion each one relates to:

• Missing or unhelpful alt text (1.1.1, Level A). Meaningful images need a text alternative that does the same job; decorative ones need an empty alt. Our guide to image optimization for websites covers how to write it.
• Low contrast (1.4.3 and 1.4.11, Level AA). Body text needs a contrast ratio of at least 4.5:1, and icons, field borders and focus indicators at least 3:1 against what's next to them.
• Things a keyboard can't reach (2.1.1, Level A, and 2.4.7, Level AA). Every link, button, menu and form control should work with the Tab and Enter keys, with a visible focus indicator.
• Unlabelled form fields and vague errors (3.3.1 and 3.3.2, Level A). Each field needs a visible label, and errors must say what went wrong in text. Our guide on how to design a contact form people finish walks through it.
• Headings used for size, not structure (1.3.1, Level A, and 2.4.6, Level AA). Screen reader users jump between headings, so the outline has to make sense.
• Links that say "click here" (2.4.4, Level A). Link text should make sense on its own or in its sentence.
• Video without captions (1.2.2, Level A). Pre-recorded video with sound needs captions.
• No page language (3.1.1, Level A). One attribute on the html element lets screen readers pronounce words correctly.

None of these needs special technology. They're decisions made in design, code and content, which is why it is usually easier to get them right before launch.

How to apply WCAG on a real site

Treat accessibility as part of how the site is built, not a scan at the end. Here is an order that works:

1. Pick a target. For most sites that means WCAG 2.2 Level AA. Write it into the brief so design, development and content all work to it.
2. Build it into the design system. Check colour pairs for contrast, design visible focus states and set minimum target sizes once, in the components, so every page inherits them.
3. Give editors the right fields. Required alt text fields, heading choices instead of font sizes and help notes on link text stop problems being added later.
4. Test with people and tools. Automated checkers catch some issues quickly, but the W3C is clear that no tool alone can determine whether a site meets accessibility standards. Our website accessibility testing checklist covers the manual checks anyone can run.
5. Keep it up. New pages, plugins and campaigns can undo earlier work, so recheck key templates after changes. Landing pages are a common gap; landing page conversion best practices includes the checks for them.

What WCAG cannot tell you is what any particular law requires of your organization. That depends on where you operate and what you do, so ask a qualified lawyer. This guide is general information, not legal advice. If you'd like help building a site with these checks in mind, talk to our in-house web team. We can design and build with accessibility in view, but we don't provide legal advice or certify a site as meeting any law or standard.