What's New in WCAG 2.2

Status, Timeline, Changes

Background: For an introduction to Web Content Accessibility Guidelines (WCAG) and more about versions 2.0 and 2.1, see the WCAG Overview.

We expect to publish WCAG 2.2 as a ‘W3C Recommendation’ web standard in August 2023.

WCAG 2.2 W3C Proposed Recommendation is the latest update published on 20 July 2023. “Proposed Recommendation” means that W3C accepted it and W3C Members vote on publishing the document as a “W3C Recommendation” web standard. The voting ends in August. WCAG 2.2 might be ready to publish soon after that, or additional W3C Member input could require more work. More about the process for completing WCAG 2.2 is in How WAI Develops Accessibility Standards through the W3C Process.

Comments

We do not plan to change the normative content in WCAG 2.2 itself. We will continue to update the Understanding documents based on feedback. To comment, please open a new issue in the WCAG GitHub repository. Create separate GitHub issues for each topic, rather than commenting on multiple topics in a single issue. If it’s not feasible for you to use GitHub, send comments in e-mail to: public-agwg-comments@w3.org

Changes from WCAG 2.1 to WCAG 2.2

The 2.0 and 2.1 success criteria are exactly the same (verbatim, word-for-word) in 2.2, with one exception: 4.1.1 Parsing is obsolete and removed from WCAG 2.2. More information is in the WCAG 2 FAQ, 4.1.1 Parsing.

WCAG 2.2 provides 9 additional success criteria from WCAG 2.1. They are included on this page.

Changes to 2.2 Draft

From the May 2023 Draft to the June 2023 publication, there are no substantive changes (only editorial changes to add links and correct punctuation).

Previous changes are listed in the changelog.

Guideline 2.4 Navigable

Provide ways to help users navigate, find content, and determine where they are.

2.4.11 Focus Not Obscured (Minimum) (AA)

In brief:

What to do: Ensure when an item gets keyboard focus, it is at least partially visible.
Why it’s important: People who can't use a mouse need to see what has keyboard focus.

Persona example — a reporter with repetitive stress injury who uses speech recognition software:

Problem: This page has a big banner that's always across the bottom. (a sticky footer) When I move focus to items, some are hidden behind the banner and I can't see them.
Works well: When I move focus to items, I can see them all.

WCAG success criteria:

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

Note: Where content in a configurable interface can be repositioned by the user, then only the initial positions of user-movable content is considered for testing and conformance of this Success Criterion.

Note: Content opened by the user may obscure the component receiving focus. If the user can reveal the focused component without advancing the keyboard focus, the component with focus is not considered hidden due to author-created content.

Understanding Focus Not Obscured (Minimum)

2.4.12 Focus Not Obscured (Enhanced) (AAA)

In brief:

What to do: Ensure when an item gets keyboard focus, it is fully visible.
Why it’s important: People who can't use a mouse need to see what has keyboard focus.

(Persona, problem, and works well same as 2.4.12 above.)

WCAG success criteria:

When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

Understanding Focus Not Obscured (Enhanced)

2.4.13 Focus Appearance (AAA)

In brief:

What to do: Use a focus indicator of sufficient size and contrast.
Why it’s important: Many people can't see small contrast differences, including older people.

Persona example — a reporter with repetitive stress injury who doesn't use a mouse:
and Retiree with low contrast sensitivity:

Problem: I can't tell where the keyboard focus is as I move around a web page or app.
Works well: I can see where the keyboard focus is as I move around a web page or app.

WCAG success criteria:

When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:

is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and

has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states

Exceptions:

The focus indicator is determined by the user agent and cannot be adjusted by the author, or

The focus indicator and the indicator's background color are not modified by the author.

Note: What is perceived as the user interface component or sub-component (to determine enclosure or size) depends on its visual presentation. The visual presentation includes the component's visible content, border, and component-specific background. It does not include shadow and glow effects outside the component's content, background, or border.

Note: Examples of sub-components that may receive a focus indicator are menu items in an opened drop-down menu, or focusable cells in a grid.

Note: Contrast calculations can be based on colors defined within the technology (such as HTML, CSS and SVG). Pixels modified by user agent resolution enhancements and anti-aliasing can be ignored.

Understanding Focus Appearance

Guideline 2.5 Input Modalities

Make it easier for users to operate functionality through various inputs beyond keyboard.

2.5.7 Dragging Movements (AA)

In brief:

What to do: For any action that involves dragging, provide a simple pointer alternative.
Why it’s important: Some people cannot use a mouse to drag items.

Persona example — a retiree with hand tremor:

Problem: I cannot hold down the mouse button and drag it accurately enough to move the items in this list.
Works well: When I click on an item in the list, I get up and down arrows and I can click those to change the order.

WCAG success criteria:

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Note: This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Understanding Dragging Movements

2.5.8 Target Size (Minimum) (AA)

In brief:

What to do: Ensure targets meet a minimum size or have sufficient spacing around them.
Why it’s important: Some people with physical impairments cannot click small buttons that are close.

Persona example — a retiree with hand tremor:

Problem: The buttons are so close, I hit "Cancel" when going for "Submit". Then I have to start all over again.
Works well: There is more space between the buttons so I don't hit the wrong button even when I'm riding on the bumpy bus.

WCAG success criteria:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target;

Equivalent: The function can be achieved through a different control on the same page that meets this criterion;

Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;

User agent control: The size of the target is determined by the user agent and is not modified by the author;

Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

Note: Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

Note: For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed top to bottom, the line-height would be horizontal.

Understanding Target Size (Minimum)

Guideline 3.2 Predictable

Make Web pages appear and operate in predictable ways.

3.2.6 Consistent Help (A)

In brief:

What to do: Put help in the same place when it is on multiple pages.
Why it’s important: People who need help can find it more easily if it's in the same place.

Persona example — a supermarket assistant with cognitive disabilities:

Problem: Whenever I use the online app to schedule my medical appointments, I can't remember what to do at each step. I've seen a Chat option in some places, but can't find it now.
Works well: When I need help, I can easily find the Chat option that's always in the lower right corner of the page.

WCAG success criteria:

If a web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple web pages within a set of web pages, they occur in the same relative order to other page content, unless a change is initiated by the user:

Human contact details;

Human contact mechanism;

Self-help option;

A fully automated contact mechanism.

Note: Help mechanisms may be provided directly on the page, or may be provided via a direct link to a different page containing the information.

Note: For this Success Criterion, the same relative order can be thought of as how the content is ordered when the page is serialized. The visual position of a help mechanism is likely to be consistent across pages for the same page variation (e.g., CSS break-point). The user can initiate a change, such as changing the page's zoom or orientation, which may trigger a different page variation. This criterion is concerned with relative order across pages displayed in the same page variation (e.g., same zoom level and orientation).

Understanding Consistent Help

Guideline 3.3 Input Assistance

Help users avoid and correct mistakes.

3.3.7 Redundant Entry (A)

In brief:

What to do: Don't ask for the same information twice in the same process.
Why it’s important: Some people with cognitive disabilities have difficulty remembering what they entered before.

Persona example — a supermarket assistant with cognitive disabilities:

Problem: Whenever I use the online app to schedule my medical appointments, I have to re-type some information that I entered in a previous step.
Works well: The app automatically fills in information that I entered in previous steps.

WCAG success criteria:

Information previously entered by or provided to the user that is required to be entered again in the same process is either:

auto-populated, or

available for the user to select.

Except when:

re-entering the information is essential,

the information is required to ensure the security of the content, or

previously entered information is no longer valid.

Understanding Redundant Entry

3.3.8 Accessible Authentication (Minimum) (AA)

In brief:

What to do: Don’t make people memorize or transcribe something to log in.
Why it’s important: Some people with cognitive disabilities cannot recall usernames and passwords, or type them.

Persona example — a supermarket assistant with cognitive disabilities:

Problem: I can never remember my password, it’s really hard to get into this app.
Works well: To get into this app, I can put my e-mail address. Then I get an e-mail message, and I can click a link in the e-mail to get into the app.

WCAG success criteria:

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

Alternative

Another authentication method that does not rely on a cognitive function test.

Mechanism

A mechanism is available to assist the user in completing the cognitive function test.

Object Recognition

The cognitive function test is to recognize objects.

Personal Content

The cognitive function test is to identify non-text content the user provided to the website.

Note: "Object recognition" and "Personal content" may be represented by images, video, or audio.

Note: Examples of mechanisms that satisfy this criterion include:

support for password entry by password managers to reduce memory need, and

copy and paste to reduce the cognitive burden of re-typing.

Understanding Accessible Authentication (Minimum)

3.3.9 Accessible Authentication (Enhanced) (AAA)

In brief:

What to do: Don’t make people recognize objects or personal information to login.
Why it’s important: Some people with cognitive disabilities cannot identify objects or recall information.

Persona example — a supermarket assistant with cognitive disabilities:

Problem: To get into this app, it's asking me to click on pictues of cats, but I can't tell which are cats.
Works well: To get into this app, I can copy and paste my password.

WCAG success criteria:

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following:

Alternative

Another authentication method that does not rely on a cognitive function test.

Mechanism

A mechanism is available to assist the user in completing the cognitive function test.

Understanding Accessible Authentication (Enhanced)

About the Personas

These personas are representations of people with disabilities developed from qualitative data on real people.

The linked persona roles go to the Stories of Web Users. That page has other personas with different disabilities.