WCAG 2.2 level AA: what changed and how to check it

WCAG 2.2 added nine success criteria to WCAG 2.1 and removed one, 4.1.1 (Parsing). Of the nine, six count for anyone who needs level AA: four are level AA (2.4.11, 2.5.7, 2.5.8 and 3.3.8) and two are level A (3.2.6 and 3.3.7), which AA also requires. The other three are level AAA. Everything else from 2.1 stays the same, so a site that already met 2.1 AA needs to test those six points and can stop testing 4.1.1.

This article covers WCAG 2.2 in the December 12, 2024 edition, the current one in October 2026, and how it relates to ABNT NBR 17225:2025, Brazil's web accessibility standard.

What WCAG 2.2 is

The Web Content Accessibility Guidelines (WCAG) are the recommendation of the W3C, the consortium that maintains web standards, on how to make pages usable by people with disabilities. Each testable requirement is called a success criterion and has a number (for example, 1.4.3), a name and a level: A, AA or AAA.

Version 2.2 became a W3C Recommendation on October 5, 2023, according to the What's New in WCAG 2.2 page. The current edition is from December 12, 2024. The W3C states that content meeting 2.2 also meets 2.0 and 2.1; the earlier versions remain valid, but the recommendation is to adopt 2.2 (WCAG 2.2, introduction). WCAG 3.0 is still a working draft and does not replace 2.2.

Conformance levels: A, AA and AAA

The levels are cumulative. To claim a level, the page must meet every criterion at that level and the levels below it (WCAG 2.2, 5.2.1).

Besides the level, WCAG has four other conformance requirements (WCAG 2.2, 5.2):

• Conformance applies to the whole page. You cannot exclude a part, and each responsive variation of the page (phone, tablet, desktop) must also conform.

• In a multi-step process, such as a checkout, every step must meet the level. If one fails, no page in the process can claim conformance.

• Only ways of using the technology that work with accessibility features count (the W3C calls this "accessibility supported").

• What does not conform cannot block use of the rest of the page. This is the non-interference requirement.

The nine new criteria in WCAG 2.2

The names below are the official WCAG names; NBR 17225 uses its own names, listed further down. Source: WCAG 2.2, New Features and the text of each criterion.

To keep the old numbering, the new criteria were placed at the end of each guideline. So a criterion's position within the guideline says nothing about its level; the level is stated on each criterion.

What was removed: 4.1.1 Parsing

4.1.1 asked for well-formed HTML: complete tags, correct nesting, no duplicate attributes and unique IDs. It existed because assistive technologies, such as screen readers, used to parse the HTML directly. According to the W3C, that no longer happens, and the problems it covered either no longer exist or are already covered by other criteria (WCAG 2.2, 4.1.1). In WCAG 2.1 itself, a note added later says to treat the criterion as always met for HTML or XML content (WCAG 2.1, 4.1.1).

Two caveats. Anyone bound by contract or policy to meet WCAG 2.0 or 2.1 may still need to test and report 4.1.1, as the W3C warns. And the Understanding Parsing document says that many issues that would have failed 4.1.1 now fail 1.3.1 (Info and Relationships) or 4.1.2 (Name, Role, Value). A duplicate ID that makes a label point to the wrong field is the kind of error that still counts.

How to check each new level A and AA criterion

Automated tools help, but the W3C is direct: they cannot determine whether a site is accessible, they only assist the evaluation, and some checks require human judgment (Selecting Web Accessibility Evaluation Tools). The same limit applies to widgets installed on top of the site, discussed in do accessibility overlays meet the law?. The six criteria below depend heavily on manual testing.

2.4.11 Focus Not Obscured (Minimum)

It fails when a sticky header, a sticky footer, a cookie banner or a chat window fully covers the element that just received focus. The W3C cites the cookie banner as a failure when it entirely hides the focused element; a well-built modal passes, because the user has to close it before continuing (Understanding 2.4.11).

1. Open the page as a new visitor, with the cookie banner and chat still on screen.

2. Navigate with Tab only, and Shift+Tab to go back, from the start to the end of the page.

3. At each stop, check that the focused element is at least partly visible. Fully hidden is a failure. Partly covered meets AA; AAA (2.4.12) requires that nothing be covered.

4. Repeat at phone width, where sticky headers take up more space.

A common fix is the CSS scroll-padding property, which reserves space for the sticky header or footer so that scrolling stops with the element visible. This is W3C technique C43.

2.5.7 Dragging Movements

This affects reorderable lists, sliders, maps, kanban boards and carousels that only respond to dragging. Keyboard support does not solve it: the W3C says keyboard equivalence alone does not meet this criterion, because someone using a touch screen may not have a keyboard (Understanding 2.5.7).

1. List the components that respond to dragging.

2. In each one, try to perform the same action with simple clicks or taps only, without holding and moving.

3. If there is no way to do it, it fails. Alternatives the W3C accepts: move up and move down buttons, clicking anywhere on the slider track, direction buttons on the map, a field to type the value.

2.5.8 Target Size (Minimum)

The target is the area that receives the click or tap of a link, button or control. It must be at least 24 by 24 CSS pixels, the CSS unit of measure, which does not depend on screen density. A smaller target passes if one of these exceptions applies (WCAG 2.2, 2.5.8):

• Spacing: a 24 CSS pixel diameter circle centered on the target does not intersect another target or the circle of another undersized target.

• Equivalent: the same function is available through another control on the page that meets the size.

• Inline: the target is inside a sentence, such as a link in the middle of a paragraph.

• User agent control: the size is the browser default and the site did not change it.

• Essential: that presentation is essential or legally required.

To test, measure small controls in DevTools: modal close buttons, social media icons, pagination, filters, carousel arrows. In the W3C example, six 20 pixel icons placed side by side fail, and the same icons with 4 pixels of space between them pass (Understanding 2.5.8). The equivalent AAA criterion, 2.5.5, asks for 44 by 44 CSS pixels.

3.2.6 Consistent Help (level A)

The criterion applies to four kinds of help: human contact details (phone, email, hours), a human contact mechanism (live chat, contact form), self-help options (such as an FAQ page) and a fully automated contact mechanism (such as a chatbot). If one of them repeats across pages, it appears in the same order relative to the rest of the content, unless the user initiates a change (WCAG 2.2, 3.2.6). The criterion does not require the site to offer help; it asks for consistency when help exists.

1. Pick pages of different types: home, category, product, cart, contact.

2. Note the position of each help mechanism in the source order, which is the screen reader's reading order, and not only its visual position.

3. Compare pages at the same screen width and zoom level. WCAG compares the order within the same variation of the page.

3.3.7 Redundant Entry (level A)

Within the same process, the site does not ask again for information the user has already given, unless it is auto-populated or offered for selection. The classic example is the "shipping address same as billing" option. Browser autofill does not count, because it is the site that has to provide the information (Understanding 3.3.7). There are three exceptions: re-entering is essential, the request exists for security (such as confirming a new password) or the earlier information is no longer valid.

1. Go through the multi-step flows: sign-up, checkout, quote request, booking.

2. Note each field that asks for something already entered earlier in the same flow.

3. Check whether it is prefilled or whether there is an option to reuse it.

4. Trigger a submission error and see whether the form keeps what was typed. The W3C uses the case of a card number that should not be wiped after a failure.

3.3.8 Accessible Authentication (Minimum)

A cognitive function test, as WCAG defines it, is a task that requires remembering, manipulating or transcribing information: memorizing a password, typing characters, spelling correctly, doing math, solving a puzzle. Name, email and phone number do not count, because they belong to the user and are the same on every site (WCAG 2.2, glossary). The login can have a step like this as long as it offers an alternative without that test or a mechanism that helps complete it. According to Understanding 3.3.8:

• A password field that accepts password managers and pasting passes. Blocking paste or autofill is a failure, unless there is an alternative.

• A CAPTCHA that asks you to type distorted characters fails without an alternative. An audio clip that asks you to transcribe what you hear does not count as an alternative.

• An object recognition CAPTCHA is accepted at level AA, but not at AAA (3.3.9).

• A two-step verification code must accept pasting. Requiring the person to type the code by hand does not meet the criterion.

• An email login link and login through an external provider via OAuth are listed as ways to comply.

To test, open the login with a password manager and see whether it fills in the username and password; try pasting the password and the verification code; find out whether there is a CAPTCHA and what kind.

How this relates to Brazil's NBR 17225 and LBI

Brazil's Inclusion Law (Lei Brasileira de Inclusão, Law 13,146/2015), in article 63, makes accessibility mandatory on the websites of companies with headquarters or commercial representation in the country and of government bodies, "in accordance with internationally adopted accessibility best practices and guidelines" (Law 13,146/2015, our translation). The law does not name WCAG.

ABNT NBR 17225:2025, "Accessibility in web content and applications: Requirements", has a first edition dated March 11, 2025 and follows the WCAG 2.2 success criteria. It splits its items into requirements and recommendations and defines two types of conformance (ABNT NBR 17225:2025, section 4):

• Regular conformance: every requirement met. The standard says it is aligned with WCAG 2.2 level AA, so a site in regular conformance also meets levels A and AA.

• Full conformance: requirements and recommendations, with a reasonable justification for each recommendation not met.

The new 2.2 criteria appear in the standard under its own names (our translations from Portuguese):

4.1.1 appears in the standard's Annex A (A.1.9), which repeats the W3C explanation that the criterion is no longer needed. One point where the NBR goes beyond WCAG AA: item 5.11.6 makes a contrast of at least 3:1 for the focus indicator a requirement, based on criteria 1.4.11 (AA) and 2.4.13 (AAA). Anyone auditing against the Brazilian standard should test this item even though 2.4.13 is AAA in WCAG.

Who is bound by the law and what it requires is covered in the main guide of this series, LBI and NBR 17225: what Brazilian law requires of a website. This article explains the technical standard; it is not legal advice.

How to check your site

The WebVyze free check analyzes the home page, with no sign-up, and points out accessibility risks under the law. It covers the part that can be automated. Criteria such as obscured focus, dragging, consistent help and authentication need someone navigating the site, as described above. For the two topics that come up most in audits, see the guides on color contrast and accessible forms.