Accessibility in depth: WCAG 2.2 and a walkthrough

WCAG 2.2 is the international web accessibility standard, with criteria at levels A, AA and AAA. It is checked with tools, a keyboard and a screen reader.

What the first pass missed

In the lesson on accessibility you made a first pass: alt text, field labels, focus order. Now let’s see how it all fits together. Start with the WebAIM Million study you met there. In its 2026 report, WCAG 2 failures were found on about 96 percent of home pages, with an average of more than fifty errors per page. The six most common: low text contrast (more than 80 percent of pages), images without alt (more than half), form fields without labels (about half), empty links, empty buttons and no page language. You know how to find and fix all six. That is the good news: most of the contribution to accessibility comes not from rare tricks but from things this part has been talking about for a while.

The bad news: WCAG 2.2 asks for more than “alt text and labels.” Let’s take the standard in parts.

Versions and levels

The WCAG standard develops in versions. 2.0 came out in 2008, 2.1 added requirements for mobile devices and people with low vision in 2018, and 2.2 became a W3C Recommendation in October 2023. Versions are backward compatible: a page that meets 2.2 meets 2.1 too (apart from one removed item).

The success criteria are grouped under the POUR principles you know, and divided into levels: A (the necessary minimum), AA (the usual target) and AAA (the strictest, not always achievable). The requirement “conforms to WCAG 2.2 AA” means that the page meets all the A and AA criteria, and in version 2.2 there are fifty-five of them. Meeting half of them and calling it conformance isn’t allowed.

What is new in WCAG 2.2

The version added nine criteria and removed one (4.1.1 Parsing, because modern browsers cope with markup errors themselves). Here are the ones you’ll meet on an ordinary site.

• 2.4.11 Focus Not Obscured (AA). When you press Tab, the focused element must not be entirely hidden under a fixed header, a cookie banner or a chat. The cure: scroll-padding-top on html equal to the height of the fixed header, and banners that don’t cover the whole page.
• 2.5.7 Dragging Movements (AA). If an action is done by dragging (a slider, sorting a list), there must be a way without dragging: “up” and “down” buttons, or a field to type a number.
• 2.5.8 Target Size, Minimum (AA). A touch target (a button, a link, an icon) is at least 24 by 24 CSS pixels, and if it is smaller, there must be enough free space around it. Fingers find 44 by 44 more comfortable, and a mouse in a shaky hand will thank you too.
• 3.2.6 Consistent Help (A). Contacts, chat and the link to help are in the same place on every page.
• 3.3.7 Redundant Entry (A). Don’t ask again for what the person already entered in this process: a delivery address twice, for example. Offer to fill it in.
• 3.3.8 Accessible Authentication, Minimum (AA). Logging in must not require remembering a password or solving a puzzle unless there is a workaround. In practice: allow pasting into the password field and filling it in with a password manager (the parts on authentication and passkeys), and don’t make people retype a string of characters from a picture.

The other three new criteria (2.4.12, 2.4.13 and 3.3.9) are at level AAA, and you meet them if you wish.

Check yourself: which WCAG 2.2 criterion says a focused element must not be hidden under a fixed header?

2.4.11 Focus Not Obscured (Minimum), level AA. It is cured with a scroll offset, scroll-padding-top.

What is usually checked, by topic

There are many criteria, so it is easier to keep topics in mind. For each topic from the HTML and CSS parts you already have a tool.

• Text and color. The thresholds from the lesson on color and contrast: normal text at least 4.5 to 1, large text (from 24 pixels, or from 18.66 if bold) at least 3 to 1 (criterion 1.4.3). Field borders, icons and the focus ring at least 3 to 1 (1.4.11). Meaning must not rest on color alone (1.4.1): a red border needs an asterisk or a word.
• Size and width. The page reads when the text is enlarged to 200 percent (1.4.4) and at a width of 320 CSS pixels without horizontal scrolling (1.4.10, the same as 400 percent zoom on a screen 1280 wide). If you have to scroll sideways on a narrow screen to read, that is a failure.
• Keyboard. Everything done with a mouse can be done with a key (2.1.1). No focus traps (2.1.2). The focus order is sensible (2.4.3). The focus is visible (2.4.7). There is a way to skip the repeated menu (2.4.1).
• Forms. A label on every field (3.3.2, 1.3.1). Autofill where it fits, with the autocomplete attribute (1.3.5). An error is named in words, next to the field, with a hint on how to fix it (3.3.1, 3.3.3), and announced to a screen reader (4.1.3).
• Movement and time. Nothing flashes more than three times a second (2.3.1). Whatever moves for more than five seconds (a carousel, a video background) can be stopped (2.2.2). Animations respect prefers-reduced-motion, as in the part on motion. A time limit can be extended (2.2.1).
• Media. Video has captions and audio has a transcript (1.2.x).
• Language. The language of the page and of its parts (3.1.1, 3.1.2): a screen reader picks its voice by lang.
• Name, role, state. A custom element tells a screen reader what it is and what state it is in (4.1.2). More on this in the next lesson.

Three passes

Checking accessibility isn’t one tool but three different points of view.

1. Automated. Lighthouse in Chrome (the Accessibility section), the axe DevTools extension, WAVE. They quickly find contrast, missing alt, empty links and wrong roles. They find some of the problems, and they will never say that an alt is meaningful or that the focus order is comfortable. Zero errors in Lighthouse doesn’t mean “accessible.”
2. Keyboard. Put the mouse away. Go through the whole page with Tab, Shift+Tab, Enter, Space and Esc. Can you see where the focus is? Did you get stuck? Can you submit the form? Then zoom the page to 200 percent and narrow the window to 320 pixels.
3. Screen reader. Turn on a screen reader (NVDA is free on Windows, VoiceOver comes with macOS and iOS, TalkBack with Android) and go through the main actions: what is announced on a button, on a field, on an error. More on this in the next lesson.

The diagram below is one contact page with nine faults. For each you can see how it looks from the three sides, and it is at once clear why one check is not enough.

A contact page with nine faults. Choose how you walk through it and fix them one at a time. The “WCAG 2.2” tag marks criteria that appeared in version 2.2.

Eyes and fingerKeyboard onlyScreen reader

• 1.4.3 Text contrast (level AA)

  Light gray text on white, a contrast of 2 to 1. It cannot be read in sunlight.

• 1.1.1 Text alternative (level A)

  The scan of the document is visible.

• 3.3.2 Field label (level A)

  The hint is only inside the field: you start typing and it vanishes.

• 2.4.7 Visible focus (level AA)

  No difference for a mouse.

• 2.4.11 Focus not obscured (level AA)WCAG 2.2

  The fixed header covers the top of the screen.

• 2.5.8 Target size (level AA)WCAG 2.2

  The “close” cross is 16 by 16 pixels. Hard to hit with a finger, nearly impossible with a mouse in a shaky hand.

• 3.1.2 Language of a part (level AA)

  No difference.

• 4.1.3 Status message (level AA)

  After an error, red text appears under the field.

• 3.3.8 Accessible authentication (level AA)WCAG 2.2

  The password field forbids pasting: you have to remember and type.

Criteria met: 0 of 9. Each fault shows from only one or two sides: you need to check all three ways.

Text alternative: the diagram lists nine faults of a contact page and describes, for each, how it looks to the eyes and finger, to the keyboard and to a screen reader, before the fix and after. Low contrast is seen only by the eyes, a missing focus ring bothers the keyboard, and the field label and error messages matter to the screen reader.

It is best to record the result of a check as a table: the criterion, where it fails, how much it matters (does it stop the main action), how to fix it, and whether it is fixed. Then you fix first whatever blocks the main action from the brief (book, buy, call), and leave the cosmetics for later.

Check yourself: why doesn’t a clean Lighthouse run prove accessibility?

Tools catch only some of the criteria. They can’t judge whether an alt is meaningful, whether the focus order is comfortable or whether error messages are clear. People check that by hand and with a screen reader.

Practice

You are in the era of 2014: sites have become responsive, and it is time to fix what stops people using them. You get a page with the faults from the diagram and a few more. Fix them and write down three problems you found yourself, with the criterion number of each.

The check looks at markup and styles: at the contrast of text and button, sizes, the focus ring, labels and languages. What it can’t see, check by hand: open the page, press Tab and go through it without a mouse, zoom to 200 percent. A criterion counts as met only when it worked for you.

If your project is in a site builder, pick a high-contrast theme, check the button colors and make sure the form fields have labels: in builders this is often set in the same place as everything else.

What used to be different

Before WCAG 2.0 (2008), sites were called accessible for having a version “for the visually impaired”: a separate simplified page, black on white with a huge font. It was rarely updated and fell behind the main one. Today we know that a separate version isn’t needed. One page, built properly, is. And 2.2 added what nobody thought about in 2008: fingers on phones, fixed headers and password managers. The standard keeps changing; always check the current version on the W3C site.