WCAG 2.2 checklist: what blocks a visitor
A WCAG checklist lists the success criteria of the Web Content Accessibility Guidelines, published by the W3C. The current version is WCAG 2.2, published on October 5, 2023 and updated on December 12, 2024. Its criteria fall into three levels, A, AA and AAA, and Level AA is the one that laws and regulations point to.
A checklist tells you what to look for, not whether a visitor can actually get through your pages with a keyboard, a screen reader or enlarged text. The accessibility pillar of our audit puts that use to the test on your pages, with the keyboard and on screen, and names what it could not check.
What WCAG 2.2 contains
WCAG 2.2 groups its criteria under four principles: content must be perceivable, operable, understandable and robust. The principles break down into 13 guidelines, and each guideline into testable success criteria.
Version 2.2 adds nine criteria to 2.1 and removes one that had become obsolete. Content that meets WCAG 2.2 also meets 2.1 and 2.0. The W3C notes that the October 2023 version is also an ISO standard, ISO/IEC 40500:2025, and encourages using the latest version.
Levels A and AA: what each one requires
Level A covers the criteria without which some visitors cannot use the content at all. Level AA adds the ones that remove common obstacles: text contrast, resized text, a visible keyboard focus. Meeting AA means meeting every Level A and every Level AA criterion.
Level AAA goes further, and the W3C itself advises against requiring it for an entire site, because some content cannot meet all of its criteria.
Two of WCAG's conformance requirements change how you read a site. Conformance applies to full pages: a banner or widget left out of the review keeps the page from conforming. And it applies to complete processes: a checkout conforms only if every step does, payment included.
The criteria that stop a visitor
Not every criterion weighs the same for the person on the page. Some are an inconvenience. These ones stop people from moving forward, and they are the ones the audit tests first.
- Keyboard (2.1.1, Level A): everything you can do with a mouse must work from the keyboard. A menu that only opens on hover shuts out anyone who is not holding a mouse.
- Focus visible (2.4.7, AA) and not obscured (2.4.11, AA, new in 2.2): keyboard users must see where they are. A removed outline, or a sticky header covering the active element, leaves them guessing.
- Name, role, value (4.1.2, A) and text alternatives (1.1.1, A): an icon button with no label is announced as "button" by a screen reader, and nothing else.
- Labels or instructions (3.3.2, A): a field whose only label is placeholder text loses its name as soon as someone starts typing.
- Contrast (1.4.3, AA): 4.5 to 1 between text and background, 3 to 1 for large text. Below that, light gray text is hard to read in bright sunlight and with low vision alike.
- Reflow (1.4.10, AA): at 320 pixels wide, the equivalent of 400% zoom on a common desktop screen, nothing may disappear and reading must not require scrolling in two directions.
- Content on hover or focus (1.4.13, AA): a tooltip or submenu must close with the Escape key, and stay open while it is being read.
- Bypass blocks (2.4.1, A): a skip link lets keyboard users reach the content without tabbing through the whole menu on every page.
This is not a replacement for the standard: it shows where visitors get stuck. Each criterion is judged in context, and a page can meet the letter of a criterion while nobody can actually use it.
What we find on the websites we audit
25%have a critical accessibility barrier repeated on 80% or more of their pages
This percentage covers about 30 websites we audited between August 14, 2026 and September 24, 2026, the ones where this point could be checked. Many were audited because a defect showed up quickly, so the figure describes our audits, not websites in general.
A critical barrier makes an element unusable, such as a button with no name or a field with no label. When it repeats on almost every page, it comes from something those pages share: the menu, the header, the footer. That usually means it can be fixed in one place.
What the audit exercises on your pages
The audit does not stop at reading the code. It does on the page what a visitor would do, and records what happens.
- The keyboard, with real presses of the Tab key. The focus indicator is measured on the page: an outline painted in a transparent color is no easier to see than no outline at all.
- Every menu, button and panel, exercised by hover, by click and by keyboard, each observed on its own: a menu that only opens with a mouse, a button the Enter key does not trigger, a panel Escape does not close, a modal that lets keyboard focus slip behind it.
- The skip link: present before the navigation, and visible when it receives focus.
- The page narrowed to 320 pixels wide, then with increased text spacing, to catch what disappears or gets cut off. And the active element that a sticky header covers.
- Text contrast, measured on the page as it renders: animations finished, without the overlay of a cookie banner, in dark mode when the site offers one, and on the image when text sits on top of it.
- The names the browser computes for links and buttons, the ones a screen reader announces: missing, generic, or identical for different destinations.
The report names each barrier, the WCAG criterion involved and the pages where it appears.
What an automated tool does not see
The W3C is plain about it: evaluation tools cannot check every aspect of accessibility automatically, and human judgment is still required. A tool reaches conclusions on what it can compute. Where it cannot, it stays silent, and that silence proves nothing.
Three cases we come across. White text on a semi-transparent background that the calculation cannot resolve to one color: no warning, yet the text is unreadable. A focus style declared in the stylesheet that paints nothing. A menu that opens on hover and closes on click: comparing the page before and after the click shows no change, even though the menu works.
These are the cases the audit handles by measuring the rendered page and exercising the controls, rather than relying only on the rules a tool can apply.
WCAG, RGAA and the law: what points to what
WCAG is not a law. National and European rules make it mandatory, often through a technical standard. In France, the RGAA turns the Level A and AA criteria of WCAG 2.1 into an obligation for public bodies and large companies. The European Accessibility Act sets requirements for websites that sell to consumers in the EU, and WCAG remains the basis for checking them.
A version 3 is in progress at the W3C. It is still a draft: it does not replace WCAG 2.2, which remains the standard to apply.
What this check doesn't tell you
Some criteria call for human judgment that we do not provide: the experience of a screen reader user, the order in which the page reads, information conveyed by color alone, video transcripts. The report names what was not checked.
We examine the pages analyzed, not the whole site or every one of its processes. The report therefore does not certify WCAG conformance, and it is not legal advice.
Read next
RGAA: France's accessibility standard
The RGAA is France's official method for checking web accessibility. Who must apply it, how it maps to WCAG, and what a conformance audit involves.
Read the guide →Accessibility statement: who needs one
An accessibility statement says how far a website meets the accessibility standard. Who must publish one in Europe, what it contains, and what we check.
Read the guide →European Accessibility Act: who it covers
Since June 28, 2025, the EAA applies to websites that sell to consumers in the EU. Who is covered, which small businesses are exempt, and what to publish.
Read the guide →