WCAG 2.2 is the latest version of the Web Content Accessibility Guidelines, adding new success criteria to WCAG 2.1, but it is not currently the legal standard under ADA Title II.
If you have been paying attention to ADA Title II compliance conversations in the past year, you have almost certainly encountered a version of this question. "We keep hearing about WCAG 2.2. Do we need to update our program? Are we supposed to be meeting a different standard now? What actually changed?"
The confusion is understandable. WCAG 2.2 was published in October 2023. The DOJ's final ADA Title II rule references WCAG 2.1. Organizations that have invested in building compliance programs around WCAG 2.1 AA are reasonably wondering whether those programs need to be rebuilt around a newer standard — and whether the regulatory ground just shifted under them.
The short answer is: the compliance standard has not changed. WCAG 2.1 AA is still what the DOJ requires. WCAG 2.2 is not currently the law.
The longer answer is more nuanced, more useful, and explains why the agencies that are positioning themselves well right now are treating WCAG 2.2 as the direction they are moving rather than something they can ignore. This guide gives you both answers in full, explains exactly what changed between WCAG 2.1 and 2.2, evaluates how those changes affect government digital services specifically, and tells you what to do with all of it.
TLDR: WCAG 2.2 vs WCAG 2.1 (Quick Answers)
- WCAG 2.1 AA = current ADA requirement
- WCAG 2.2 = newer standard, not yet law
- WCAG 2.2 adds 9 new criteria
- Most WCAG 2.1 work carries forward
- Smart agencies are building toward 2.2 now
What WCAG Is and How Accessibility Standards Evolve
Before getting into the differences between 2.1 and 2.2, it helps to understand how WCAG is developed and why version numbers matter.
WCAG — Web Content Accessibility Guidelines — is published by the World Wide Web Consortium (W3C) through a working group called the Accessibility Guidelines Working Group (AG WG). W3C is an international standards body, not a government agency. WCAG is a technical standard, not a law. It becomes legally relevant when laws and regulations reference it — which is exactly what the DOJ's ADA Title II rule does.
WCAG versions are backwards compatible. Every success criterion in WCAG 2.0 is carried forward into WCAG 2.1. Every success criterion in WCAG 2.1 is carried forward into WCAG 2.2 with one exception, which we will cover in detail. This means that work done toward WCAG 2.1 AA conformance is not wasted if the regulatory standard eventually moves to WCAG 2.2 AA. An agency that achieves WCAG 2.1 AA conformance is most of the way to WCAG 2.2 AA conformance — because WCAG 2.2 AA includes everything in WCAG 2.1 AA plus nine new criteria.
This backwards compatibility is why the version question is less disruptive than it might appear. Building a compliance program around WCAG 2.1 AA today is not building toward an obsolete standard. It is building the foundation on which WCAG 2.2 AA conformance sits.
What the ADA Title II Rule Requires (WCAG 2.1 AA)
The DOJ published its final ADA Title II rule on April 24, 2024. The rule establishes WCAG 2.1 Level AA as the technical standard for digital accessibility compliance for state and local government entities. It does not reference WCAG 2.2.
This is the definitive statement of the current legal standard. As of this writing, WCAG 2.1 AA is what ADA Title II requires. Full stop.
The compliance deadlines under the final rule are:
Entities serving populations of 50,000 or more: April 24, 2026 Entities serving populations under 50,000 and special district governments: April 26, 2027
These deadlines apply to WCAG 2.1 AA conformance — not WCAG 2.2.
What about future regulatory updates?
The DOJ's rule includes language acknowledging that technical standards evolve. The rule is written to allow future updates to the technical standard without requiring a full rulemaking process to adopt newer WCAG versions as they become available. This means WCAG 2.2 — and eventually WCAG 3.0 — could be adopted through a streamlined regulatory update rather than a new full rulemaking.
No timeline for such an update has been announced. The regulatory standard today is WCAG 2.1 AA. Compliance programs should be built to WCAG 2.1 AA. But agencies should understand that the standard is likely to evolve and that building toward WCAG 2.2 AA is prudent forward positioning.
What Changed in WCAG 2.2 (New Success Criteria Explained)
WCAG 2.2 was published in October 2023. It introduced nine new success criteria across Level A and Level AA while carrying forward all Level A and Level AA criteria from WCAG 2.1 with one modification (4.1.3 Status Messages was adjusted). It also formally deprecated one criterion from WCAG 2.1 — 4.1.1 Parsing — which was removed because modern browser handling has made it redundant.
Here is a complete breakdown of every new criterion, what it requires, and what it means specifically for government digital services.
New Level A Success Criteria
Level A criteria represent the most fundamental accessibility requirements — failures that completely block access for some users.
2.4.11 Focus Not Obscured (Minimum) — Level AA
Wait — this is actually Level AA. Let me reorder correctly.
There are no new Level A criteria in WCAG 2.2. All nine new criteria are at Level AA or Level AAA. This is relevant context: the new requirements in WCAG 2.2 add to the AA layer without introducing new absolute minimums at Level A.
New Level AA Success Criteria
These are the criteria that would be required if WCAG 2.2 AA becomes the regulatory standard. For agencies doing forward-looking compliance planning, these are the gaps to understand.
2.4.11 Focus Not Obscured (Minimum)
What it requires: When a user interface component receives keyboard focus, the component is not entirely hidden from view by author-created content — such as a sticky header, a cookie consent banner, a fixed footer, or a floating chat widget.
Why it was added: Modern web design has proliferated sticky and fixed elements. A sticky navigation header that is 80px tall can completely hide the currently focused element on a page, leaving keyboard users with an invisible cursor. Focus Not Obscured (Minimum) requires that the focused component is at least partially visible — not entirely covered.
What it means for government websites: Many government websites use sticky headers with site navigation. Many use cookie consent banners that appear at the top of the page. Many use live chat widgets that float over page content. If any of these elements completely obscure a focused component on the page, this criterion fails.
Testing: Tab through pages on your site while observing whether the focused element is ever entirely hidden behind a sticky or fixed element. If a form field, a link, or a button disappears entirely behind a sticky header when it receives focus, that is a 2.4.11 failure.
Common fix: Add scroll padding or scroll margin to the page to ensure that when focus moves to an element, the page scrolls far enough to bring the element fully below the sticky content. In CSS: scroll-padding-top: [height of sticky header]px;
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
This is the stricter version at Level AAA, requiring the focused component to be fully visible — not just partially visible. Since it is Level AAA it is not required for compliance at the AA level.
2.4.13 Focus Appearance — Level AA
What it requires: When a keyboard focus indicator is visible, it must meet minimum size and contrast requirements. Specifically: the focus indicator must be at least as large as a 2-pixel-thick perimeter around the component, and the change in contrast between the focused and unfocused states must meet a 3:1 contrast ratio against adjacent colors.
Why it was added: WCAG 2.1 required that focus indicators exist and be visible (Success Criterion 2.4.7), but did not specify how large or how visible. Many websites implemented technically "visible" focus indicators that were so thin, low-contrast, or small that they were effectively invisible to users with low vision. 2.4.13 quantifies what "visible" actually means.
What it means for government websites: Many government websites implement custom focus indicators that are technically visible but fail the size and contrast requirements of 2.4.13. A 1px dotted outline in a color that is close to the background color will fail. A small highlight on a link text that does not extend to the full component boundary will fail.
Testing: Tab through interactive elements while measuring the focus indicator dimensions and contrast ratio using the browser's inspector and a contrast checker. The focus indicator perimeter must be at least 2px thick or the area of the indicator must meet an equivalent threshold.
Common fix: Implement focus indicators with a minimum 3px solid outline with a color that achieves 3:1 contrast against both the component background and the surrounding page background. The CSS approach: :focus-visible { outline: 3px solid #005ea2; outline-offset: 2px; } provides a clearly visible, sizeable focus indicator that works well in most government design contexts.
2.5.3 Label in Name (updated application)
This criterion existed in WCAG 2.1. WCAG 2.2 did not add it but clarified its application to certain icon-based controls. Not a new criterion.
3.2.6 Consistent Help — Level A
Wait — this is actually Level A. Let me correctly classify all nine new criteria:
The nine new success criteria in WCAG 2.2, correctly classified:
Level A (3 new):
- 3.2.6 Consistent Help
- 3.3.7 Redundant Entry
- 3.3.8 Accessible Authentication (Minimum)
Level AA (3 new):
- 2.4.11 Focus Not Obscured (Minimum)
- 2.4.12 Focus Appearance (note: this is actually Level AA in WCAG 2.2 — 2.4.13 is the AAA version)
- 3.3.9 Accessible Authentication (Enhanced) — actually Level AAA
Let me present these correctly and completely:
All Nine New WCAG 2.2 Success Criteria
2.4.11 Focus Not Obscured (Minimum) — Level AA Covered above. The focused component must not be entirely hidden by sticky/fixed content.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA The stricter version requiring the focused component to be fully visible. Not required for AA conformance.
2.4.13 Focus Appearance — Level AA Covered above. Focus indicators must meet minimum size and contrast requirements.
2.5.7 Dragging Movements — Level AA
What it requires: Any functionality that requires a dragging movement — click and drag, swipe, drag and drop — must also be achievable with a single pointer action without dragging. In other words, if you can drag something to accomplish an action, there must be a way to accomplish the same action by clicking or tapping without dragging.
Why it was added: Dragging movements are inaccessible to users with motor disabilities who have difficulty with fine motor control, to users of switch access devices, and to some users of voice control software. Requiring a single-pointer alternative ensures these users can accomplish the same tasks.
What it means for government websites: This criterion is most relevant to interfaces that include drag-and-drop functionality — reorderable lists, slider controls, sortable table columns, map interactions requiring drag to pan, file upload drag zones. Government websites with interactive mapping tools, document management interfaces with reorderable items, or custom slider inputs for range selection need to evaluate these components.
The fix is ensuring that every drag interaction has an equivalent single-click or single-tap alternative. A drag-to-reorder list must also have up/down arrow buttons or a dropdown that allows item reordering without drag. A range slider that can be dragged must also accept click-to-set-point interaction or direct value entry.
2.5.8 Target Size (Minimum) — Level AA
What it requires: The size of the target for pointer inputs — the clickable or tappable area of a control — must be at least 24x24 CSS pixels, with exceptions for inline text links and controls whose size is determined by the browser.
Why it was added: Small click targets are inaccessible to users with motor disabilities affecting fine motor control, to users of touch devices who cannot point precisely, and to users with tremors. Many modern interfaces use very small icon buttons, close buttons, and action links that are difficult or impossible to activate reliably.
What it means for government websites: This is one of the most practically impactful criteria in WCAG 2.2 for government websites. Government sites frequently have small "close" buttons on modal dialogs, small icon buttons in navigation menus, small action links in data tables ("edit," "delete," "view"), and small form field clear buttons. All of these need to meet the 24x24 CSS pixel minimum.
Note that the target size requirement is about the pointer target — the clickable area — not the visual size of the element. CSS padding can increase the target size without changing the visual appearance of the element.
Testing: Use browser developer tools to inspect the computed width and height of interactive elements. Any interactive element smaller than 24x24 CSS pixels in its pointer target area fails 2.5.8.
3.2.6 Consistent Help — Level A
What it requires: If a web page provides any of the following — human contact details, a human contact mechanism, a self-help option, or a fully automated contact mechanism — it must be provided in a consistent location across pages.
Why it was added: Users who need help finding or using content — particularly users with cognitive disabilities — benefit from being able to find help resources in a consistent, predictable location. If a chat widget appears in the bottom right corner on some pages and is absent on others, users who rely on it have no reliable way to find it.
What it means for government websites: If your website has a live chat widget, a "Contact Us" link, a help center link, or a feedback mechanism, it must appear in a consistent location across all pages. This is primarily relevant to sites where these elements appear inconsistently — on the homepage and service pages but not on document pages, or only on certain sections of the site.
For government websites that already maintain consistent navigation with a contact link — which most do — this criterion is largely already met. Audit for inconsistency in chat widget placement and self-help resource availability across different sections of the site.
3.2.7 Visible Controls — Level AA
What it requires: User interface components — meaning buttons, links, and other interactive elements — must be visible without requiring pointer hover or keyboard focus to reveal them. Controls that are only visible on hover fail this criterion.
Why it was added: "Hover to reveal" controls — menu items, action buttons, and other interactive elements that only appear when a user hovers over a region — are inaccessible to keyboard users (who cannot hover) and to users with motor disabilities who cannot hover precisely. This criterion requires that all controls are persistently visible.
What it means for government websites: Hover-to-reveal navigation menus, inline editing buttons that appear on row hover in data tables, action buttons in card layouts that only appear on hover, and tooltip-style interactive elements that are only accessible via hover all fail this criterion.
This is one of the more impactful criteria for government website design systems. Many government sites use hover states as the primary reveal mechanism for secondary actions. Complying with 3.2.7 requires either making these controls persistently visible or providing an always-visible alternative path to the same functionality.
3.3.7 Redundant Entry — Level A
What it requires: Information that has already been provided by the user in a process must not be required to be entered again in the same process, unless re-entering it is essential, the information is required for security purposes, or the previously entered information is no longer valid.
Why it was added: Requiring users to re-enter information they have already provided is a significant barrier for users with cognitive disabilities who may not remember what they entered, users with motor disabilities for whom data entry is effortful, and users who process information more slowly. Multi-step forms and processes should remember what the user has already entered.
What it means for government websites: This criterion is most relevant to multi-step government service applications where users enter personal information early in the process and are then asked to confirm or re-enter the same information in a later step. A common example: entering an email address in step 1 for account creation, then being asked to enter the same email address again in step 4 for correspondence preferences.
The fix is auto-populating fields with previously entered information where it is needed again, or offering the user the option to copy previously entered information rather than requiring re-entry from scratch.
3.3.8 Accessible Authentication (Minimum) — Level A
What it requires: If an authentication process requires a cognitive function test — solving a puzzle, memorizing information, transcribing characters, performing calculations — there must be an alternative authentication method that does not require a cognitive function test, unless the test is for security purposes with freely available user agent support, or the test is to confirm the user is still in the same authentication session.
Why it was added: Cognitive function tests in authentication — particularly CAPTCHA — are inaccessible to users with cognitive disabilities. CAPTCHA challenges that require recognizing distorted text, identifying objects, solving visual puzzles, or performing other cognitive tasks are fundamentally inaccessible to users who cannot perform those tasks.
What it means for government websites: This is the WCAG 2.2 criterion that most directly addresses the CAPTCHA problem covered in the courts accessibility section of this series. Any government login, form submission, or portal access that requires a CAPTCHA or other cognitive test without an accessible alternative fails this criterion.
The compliant approaches are the same as described in the courts section: reCAPTCHA v3 (invisible, no user interaction required), alternative authentication methods (email verification, SMS verification), or waiving CAPTCHA for government portals where bot protection can be achieved through other means.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
The stricter version prohibiting cognitive function tests in authentication entirely, without exception. Level AAA, not required for AA conformance.
The One Criterion Removed: 4.1.1 Parsing
WCAG 2.2 formally deprecated and removed Success Criterion 4.1.1 Parsing, which required that markup be valid and well-formed. This criterion has been effectively redundant for years because modern browser error handling corrects most parsing errors automatically. The removal is a recognition of this technical reality rather than a lowering of accessibility expectations.
For practical purposes, this removal does not change what agencies should do. Well-formed, valid HTML remains a development best practice and the foundation of accessible markup regardless of whether it is formally required by a success criterion.
WCAG 2.1 vs WCAG 2.2 Gap Analysis for Government Websites
For agencies currently building or maintaining WCAG 2.1 AA compliance programs, the relevant question is: what do we need to add to achieve WCAG 2.2 AA conformance?
The answer is the five Level AA criteria that are new in WCAG 2.2:
- 2.4.11 Focus Not Obscured (Minimum) — Ensure focused elements are not entirely hidden behind sticky/fixed content
- 2.4.13 Focus Appearance — Ensure focus indicators meet minimum size and contrast requirements
- 2.5.7 Dragging Movements — Ensure drag interactions have single-pointer alternatives
- 2.5.8 Target Size (Minimum) — Ensure interactive elements have minimum 24x24px target areas
- 3.2.7 Visible Controls — Ensure controls are visible without requiring hover to reveal
Plus the three Level A criteria that would be required even at Level A conformance:
- 3.2.6 Consistent Help — Ensure help mechanisms appear in consistent locations
- 3.3.7 Redundant Entry — Do not require re-entry of previously provided information
- 3.3.8 Accessible Authentication (Minimum) — Provide alternatives to cognitive function tests in authentication
For most government websites already working toward WCAG 2.1 AA conformance, criteria 6, 7, and 8 are the ones most likely to require new work. Consistent help is often already met. Redundant entry affects multi-step form flows — which are common in government service applications. Accessible authentication affects any portal or form that uses CAPTCHA — which is extremely common in government digital environments.
Among the Level AA criteria, Focus Appearance (2.4.13) and Target Size (2.5.8) are the ones most likely to require design system changes. Focus indicator implementations that were minimal under WCAG 2.1 may fall below the quantified threshold in WCAG 2.2. Small action buttons and icon controls in data tables, card layouts, and toolbars are frequently below the 24x24 CSS pixel minimum.
What Public Agencies Should Do About WCAG 2.2 Right Now
The answer here is tiered by where your agency currently is in its compliance program.
If you have not yet started a WCAG 2.1 AA compliance program:
Start there. WCAG 2.1 AA is the current legal requirement. A program built to WCAG 2.1 AA is the foundation everything else rests on. Do not defer starting because you are waiting for clarity on WCAG 2.2. The compliance deadline for WCAG 2.1 AA is April 2026 for larger entities and April 2027 for smaller ones. WCAG 2.2 is not the current law.
If you are actively working toward WCAG 2.1 AA conformance:
Note the five new Level AA criteria and evaluate your current work against them. In particular:
Evaluate your focus indicator implementation against the 2.4.13 quantified requirements now — it is better to build a compliant focus indicator once than to implement one that meets WCAG 2.1 and then revise it for WCAG 2.2.
Evaluate whether your authentication flows (login portals, form submissions with CAPTCHA) use cognitive function tests without accessible alternatives — the 3.3.8 requirement will likely become regulatory eventually.
Evaluate your interactive element target sizes — the 24x24 CSS pixel minimum in 2.5.8 is a design system change that is easier to implement during a component build than to retrofit.
If you have achieved or are close to WCAG 2.1 AA conformance:
Run the WCAG 2.2 gap analysis. Evaluate your site against the eight new criteria (five Level AA, three Level A). Document the findings. Prioritize the criteria most likely to affect government digital services: focus appearance, target size, accessible authentication, and redundant entry in multi-step forms.
Building toward WCAG 2.2 AA conformance positions your agency ahead of the regulatory curve and improves the actual accessibility of your services for users whose needs the new criteria were designed to address — particularly users with cognitive disabilities and users with motor disabilities.
If you are procuring a new website or technology platform:
Specify WCAG 2.2 AA in your RFP and contract requirements, not WCAG 2.1 AA. A platform built to WCAG 2.2 AA today will be ahead of the regulatory standard and unlikely to require significant rework when the standard is updated. A platform built only to WCAG 2.1 AA today may require remediation work when WCAG 2.2 becomes the regulatory standard.
WCAG 3.0: What Is It and Should Agencies Be Thinking About It?
WCAG 3.0 is the next major version of the accessibility guidelines currently in development by the W3C Accessibility Guidelines Working Group. It represents a more fundamental rethinking of the guidelines framework — moving away from the binary pass/fail, level-based structure of WCAG 2.x toward a more flexible, outcome-based approach with scoring and conformance options.
WCAG 3.0 is not close to publication. As of this writing, it is in Working Draft status — a very early stage of the W3C standards process. Publication as a final standard is years away, and regulatory adoption would follow publication by additional years.
Government agencies should not be planning compliance programs around WCAG 3.0. It is too early in development to predict its final requirements. The current legal standard is WCAG 2.1 AA. The near-term likely evolution is WCAG 2.2 AA. WCAG 3.0 is a longer-horizon development that agencies should monitor but not operationalize.
The Timeline Summary
To summarize the version landscape clearly:
WCAG 2.0 — Published 2008. The original standard. Still referenced in older regulations but superseded by 2.1 for modern compliance purposes.
WCAG 2.1 — Published 2018. The current ADA Title II legal standard. Required by the DOJ's 2024 final rule. Compliance deadline: April 24, 2026 for larger entities; April 26, 2027 for smaller entities and special districts.
WCAG 2.2 — Published October 2023. Nine new criteria (five at Level AA relevant to compliance programs). Not yet the legal standard. The direction best-practice compliance programs are moving.
WCAG 3.0 — In development. Years from publication. Not a current compliance consideration.
The Bottom Line
WCAG 2.2 does not change what the law currently requires. The DOJ's final rule specifies WCAG 2.1 AA and your compliance program should be built to WCAG 2.1 AA.
WCAG 2.2 does change what best-practice compliance looks like. The nine new criteria — particularly focus appearance, target size, accessible authentication, and visible controls — address real accessibility barriers for real users with disabilities. They represent where the standard is going and where well-resourced, forward-looking compliance programs are moving now.
The agencies that are positioned well are the ones that are building WCAG 2.1 AA programs designed with WCAG 2.2 in mind — implementing compliant focus indicators with the size and contrast values WCAG 2.2 requires, building interactive elements at the target sizes WCAG 2.2 specifies, replacing CAPTCHA with accessible alternatives that WCAG 2.2 mandates.
That approach costs no more than building to WCAG 2.1 alone. It protects the investment against the regulatory update that is likely to come. And it produces a more accessible digital environment right now — which is, ultimately, the point.
Related:
How to Train Your Government Staff on Accessibility
FAQ: WCAG 2.2 and ADA Title II Compliance for Public Agencies
Is WCAG 2.2 required under ADA Title II?
No. The DOJ's 2024 final ADA Title II rule specifies WCAG 2.1 Level AA as the technical standard for digital accessibility compliance for state and local government entities. WCAG 2.2 is not currently the legal requirement. Government agencies should build their compliance programs to WCAG 2.1 AA, which is the current regulatory standard, while understanding that the standard is likely to evolve.
What changed between WCAG 2.1 and WCAG 2.2?
WCAG 2.2 introduced nine new success criteria while carrying forward all criteria from WCAG 2.1 with one exception — 4.1.1 Parsing was deprecated and removed. The five new Level AA criteria most relevant to government compliance programs are: 2.4.11 Focus Not Obscured (Minimum), 2.4.13 Focus Appearance, 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), and 3.2.7 Visible Controls. Three new Level A criteria were also introduced: 3.2.6 Consistent Help, 3.3.7 Redundant Entry, and 3.3.8 Accessible Authentication (Minimum).
If our agency achieves WCAG 2.1 AA conformance, how much additional work is WCAG 2.2 AA?
The gap between WCAG 2.1 AA and WCAG 2.2 AA is the eight new Level A and Level AA criteria listed above. For most government websites, the criteria that require the most new work are: Focus Appearance (2.4.13) — quantified focus indicator requirements that may exceed current implementations; Target Size (2.5.8) — a minimum 24x24 CSS pixel target area for interactive elements that many small action buttons and icon controls fail; Accessible Authentication (3.3.8) — replacing CAPTCHA or providing accessible alternatives, which is a common gap in government portals; and Redundant Entry (3.3.7) — auto-populating previously entered information in multi-step forms, which affects government service applications.
Should government agencies specify WCAG 2.1 or WCAG 2.2 in new contracts and RFPs?
For new procurements — website builds, CMS platforms, payment portals, and other technology that will be in service for several years — specifying WCAG 2.2 AA in contracts and RFPs is the more forward-looking approach. A platform built to WCAG 2.2 AA today exceeds the current legal standard and is unlikely to require significant remediation when the regulatory standard is updated. The additional requirements over WCAG 2.1 AA are not large — for a vendor building accessibly, implementing WCAG 2.2 AA does not represent significantly more work than WCAG 2.1 AA. Specifying the higher standard protects the procurement investment.
What is WCAG 3.0 and should government agencies be planning for it?
WCAG 3.0 is the next major version of the accessibility guidelines, currently in early Working Draft stage at the W3C. It represents a significant rethinking of the guidelines framework and is years away from publication as a final standard. Regulatory adoption would follow publication by additional years. Government agencies should not build compliance programs around WCAG 3.0. Monitor its development through the W3C Accessibility Guidelines Working Group publications, but operationalize only WCAG 2.1 AA (current law) and WCAG 2.2 AA (best practice positioning for the near-term regulatory evolution).
Does WCAG 2.2 address accessibility for users with cognitive disabilities more than WCAG 2.1 did?
Yes — cognitive accessibility is one of the primary focuses of the new criteria added in WCAG 2.2. Redundant Entry (3.3.7) reduces the cognitive burden of re-entering information in multi-step processes. Accessible Authentication (3.3.8) addresses CAPTCHA and other cognitive function tests that are inaccessible to users with cognitive disabilities. Consistent Help (3.2.6) provides predictable access to help resources. Visible Controls (3.2.7) eliminates hover-to-reveal patterns that require users to remember where hidden controls are located. Focus Not Obscured (2.4.11) and Focus Appearance (2.4.13) support users with attention and low vision who rely on clear visual focus indicators. WCAG 2.2 represents a meaningful step forward in cognitive accessibility relative to WCAG 2.1.