Getting to know WCAG 2.2

Purpose 

The goal of introducing WCAG 2.2 was to improve accessibility guidance for three major groups: 

1. Users with cognitive or learning disabilities 

2. Users with low vision 

3. Users with disabilities on mobile devices 

These guidelines also make web content more usable by older individuals with changing abilities due to aging, and often improve usability for users in general. 

How it works 

WCAG 2.2 builds on WCAG 2.0 and 2.1. WCAG 2.2 uses the same conformance model as WCAG 2.0. It is intended that sites that conform to WCAG 2.2 also conform to WCAG 2.0 and WCAG 2.1, which means they meet the requirements of any policies that reference WCAG 2.0 or WCAG 2.1, while also better meeting the needs of users on the current web. 

What has changed

Added 

• 2.4.11 Focus Not Obscured (Minimum) (Level AA) 

• 2.4.12 Focus Not Obscured (Enhanced) (Level AAA) 

• 2.4.13 Focus Appearance (Level AAA) 

• 2.5.7 Dragging Movements (Level AA) 

• 2.5.8 Target Size (Minimum) (Level AA) 

• 3.2.6 Consistent Help (Level A) 

• 3.3.7 Redundant Entry (Level A) 

• 3.3.8 Accessible Authentication (Minimum) (Level AA) 

• 3.3.9 Accessible Authentication (Enhanced) (Level AAA) 

Removed 

• 4.1.1 Parsing (Level A) 

New criteria 

2.4.11 Focus Not Obscured (Minimum) (Level AA) 

The guideline for Focus Not Obscured (Minimum) states that when a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content. 

Some cases when this may occur include websites or applications with cookie banners or sticky headers or footers. 

This Level AA criteria has some flexibility, and the component may be partially hidden. There are also exceptions for cases where the content has been repositioned by the user or opened by the user. 

For example, in the Webflow screenshot in Figure 1, the focus indicator on the thumbnail is partially obscured by the sticky header. However, for Focus Not Obscured (Minimum), this is acceptable. 

Open

Figure 1 – Example of Focus Not Obscured (Minimum) 

2.4.12 Focus Not Obscured (Enhanced) (Level AAA)   

The guideline for Focus Not Obscured (Enhanced) states that when a user interface component receives keyboard focus, no part of the component is hidden due to author-created content. 

The optimal way to prevent this is to design your user interface so that no elements are sticky or floating. If this is not feasible, another option your team may consider is the CSS property for scroll padding. 

For example, in the Bootstrap screenshot in Figure 2, when the focus indicator is on the link the page scrolls to ensure that the item that is receiving focus does not get obscured by the header. Try it for yourself at Bootstrap (getbootstrap.com).

Open

Figure 2 – Example of Focus Not Obscured (Enhanced) 

People who benefit from Focus Not Obscured (Minimum) and Focus Not Obscured (Enhanced) include: 

• People who use a keyboard  

• People who have limited vision  

• People who have difficulty with memory or attention 

2.4.13 Focus Appearance (Level AAA) 

Focus Appearance states that “When the keyboard focus indicator is visible, one or both of the following are true:  

1. The entire focus indicator meets all the following: 

• encloses the user interface component or sub-component that is focused, and  

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

• has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors. 

2. An area of the focus indicator meets all the following: 

• is at least as large as the area of a 1 CSS pixel thick perimeter of the unfocused component or sub-component, or is at least as large as a 4 CSS pixel thick line along the shortest side of the minimum bounding box 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, and  

• has a contrast ratio of at least 3:1 against adjacent non-focus-indicator colors, or is no thinner than 2 CSS pixels.”

Prior to the introduction of WCAG 2.2, there were two existing criteria that relate to visible focus. The first is Focus Visible, which was introduced with WCAG 2.0, but it does not specify how visible the focus indicator needs to be. The second is Non-text Contrast, which provides minimum contrast requirements between adjacent contrast for a focus indicator. But it was determined that these were not sufficient. 

Three things can affect the visibility of a focus indicator: 

• The change of colour or contrast from the original colour  

• The size and thickness of the change  

• The difference of colour or contrast from the adjacent colours 

The illustration provided in Figure 3 shows an example of the requirements applied to the entire focus indicator:

Pass 

• There is a border enclosing the component and there is a 3:1 contrast ratio between the focus indicator colour and the adjacent colours 

Fail 

• The first example does not have sufficient contrast between the component and the focus indicator 

• The second example does not have sufficient contrast between the focus indicator and adjacent colours 

The illustration provided in Figure 4 shows an example of the requirements applied to an area of the focus indicator: 

Pass 

• The focus indicator is at least 4px and there is sufficient contrast between the indicator and the component and the surrounding colours  

Fail 

• The first example does not have a focus indicator that meets the minimum thickness  

• The second example does not have sufficient contrast between the component and the focus indicator

People who benefit from Focus Appearance include:   

• People who use a keyboard  

• People with limited vision   

• People who have difficulty with memory or attention 

2.5.7 Dragging Movements (Level AA) 

The guideline for Dragging Movements states that any functionality that uses a dragging movement can be achieved by an alternative method.  

For example, in the Trello screenshot in Figure 5, there are two ways for users to reorder the items in the list. The first option is by dragging, and the second option is by using the arrow icons. 

One of the most common questions about this new criterion is, why does dragging movements need its own criterion since keyboard accessibility is already covered in the existing WCAG guidelines? 

This criterion has a different intended audience. Dragging Movements is intended to support people using touchscreen devices who may have challenges with dexterity. 

2.5.8 Target Size (Minimum) (Level AA)  

The guideline for Target Size states that interactive elements have a target size of at least 24 x 24 CSS pixels or are far enough apart so that people do not select the wrong element by mistake. 

The most straightforward way to meet this criterion is by having the minimum target size be 24px by 24px. However, this can also be achieved by using a target offset of 24px. 

The illustration provided in Figure 6 shows how target offset works. The distance is measured from the farthest point of target 1 to the nearest point of target 1. 

The illustration provided in Figure 7 shows an example of a pass scenario, where the target offset equals 24px, and a fail scenario, where the target offset does not equal 24px. 

People who benefit from Target Size (Minimum) are users who experience: 

• Difficulty with fine motor movement  

• Difficulty with mobility or motor skills 

3.2.6 Consistent Help (Level A)  

The guideline for Consistent Help states that, if a help mechanism is provided, including human contact details, a human contact mechanism, a self-help option or a fully automated contact mechanism, it should be provided in a consistent location across pages. 

If your organization or business line has many ways for people to contact them, you could provide a link in a consistent location across all pages, that would direct the user to a page that lists all the available contact methods. 

For example, in the Wix screenshot in Figure 8, here is a link to “Support” on the top navigation bar. This menu item is present on all pages and links to a page that details all the available help options. 

3.3.7 Redundant Entry (Level A)  

The guideline for Redundant Entry states that users should not have to re-enter information they have already provided while completing a task. This applies when the user is completing a task but does not apply if they have navigated away from a task, if there is a security risk, or if the previously entered information is no longer valid. 

Some ways this can be solved is by: 

• Auto-populating information  

• Allowing the user to select from a drop-down  

• Allowing the user to opt-in and copy  

For example, in the Shopify screenshot in Figure 9, the user has the option to select to prepopulate the same address for their billing information as their shipping information. This is a good illustration of not requiring the user to enter the same information twice within the same task. 

People who benefit from Redundant Entry include: 

• People who have difficulty with short-term memory 

• People who experience mental fatigue 

3.3.8 Accessible Authentication (Minimum) (Level AA)  

The guideline for Accessible Authentication (Minimum) states that “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.” 

In summary, this guideline explains that you should not make people memorize or transcribe something to login. An application or website can fail Accessible Authentication (Minimum) if it blocks password managers or if it prevents users from pasting their password or code into an input field. 

One way this can be solved is by using web authentication. This is when the browser offloads the authentication to your device. For example, prompting the user to enter a pin from their device or biometrics like face recognition or fingerprint scan and then it is up to the user to choose which authentication method works the best for them.  

Another method can be to use a third-party authentication method, like Google or Microsoft. These tools often give users multiple options for how to authenticate. 

3.3.9 Accessible Authentication (Enhanced) (Level AAA) 

Accessible Authentication (Enhanced) is a step up from Accessible Authentication (Minimum) and removes the exceptions for object recognition and personal content. 

People who benefit from Accessible Authentication (Minimum) and Accessible Authentication (Enhanced) are users who experience: 

• Difficulty with memory  

• Difficulty with language or literacy  

• Difficulty with attention  

• Difficulty with mobility or motor skills 

Resources 

Web Content Accessibility Guidelines (WCAG) 2.2 (w3.org) 

New Success Criteria in WCAG 2.2 - TPGi