Assessing components and patterns for WCAG 2.2

Published in

IBM Design

5 min readAug 5, 2024

Version 2.2 of the Web Content Accessibility Guidelines, released in October 2023, introduces six new requirements at the A/AA level. Jess Lin and I created the following decision trees to help you quickly assess your existing component and pattern libraries for these considerations.

As with any quick check, we’ve sacrificed some detail for speed. If your response to any of these decision tree statements is False, you can be comfortable that you have met the requirement. But True responses signal a need for further investigation.

Component-level considerations

The key considerations for three of the new requirements are mostly applicable to components. Use these quick decision trees to see if components in your asset libraries need further review.

1. Dragging Movements

A decision tree asking if the interaction uses dragging, and showing a slider as an example. If true, and there is no other way to operate it with a mouse, an issue should be opened to do further review. — Check #1: Do components rely on dragging interactions?

2.5.7 Dragging Movements is all about making sure there is no reliance on dragging interactions. So, if your component involves any dragging, you need to confirm there is another way to achieve the same function with your mouse.

Our user testing suggests many people conflate this with a need for a keyboard alternative to dragging. That’s already covered by 2.1.1 Keyboard. The new need is for users to be able to perform the task another way with a pointer.

The visual example shows a volume slider. What are some other ways to operate it besides dragging? 1) Allow the user to click anywhere on the slider range to reposition; 2) Add + and − buttons for pointer-operable incrementers; 3) Provide an input so someone can type in the value directly.

For other components, an alternative to dragging might be through a menu (for instance to move an issue around on a project board).

2. Target size

A decision tree asking if there are small interactive icons or controls, including ones that appear on hover. If true, is the hit area of any target less than 24x24 pixels? If true, are they so tightly spaced that a 24 pixel diameter circle positioned on each would overlap with other targets? If true, an issue should be opened to do further review. — Check #2: Are any targets too small or close together?

2.5.8 Target Size (Minimum) ensures it is easier to operate objects on the page. So, if you have small interactive controls or icons, make sure they are at least 24x24 CSS pixels, or that under-sized controls have some space around them.

Our user testing suggests that someone familiar with all the variations of a component should be involved with this check, because on more complex components such as data tables, operable controls are not always visible without interaction. We specifically call out objects that appear on hover. They are often small and positioned close to other controls.

3. Focus not obscured

2.4.11 Focus Not Obscured (Minimum) ensures sighted users can find the item that has keyboard focus. If new content appears in an interaction, you need to make sure it either doesn’t cover up other content, or it goes away when something else gets focus.

Some designers only concern themselves with pointer interaction. Here, we want to make sure that keyboard focus is preserved and always visible. Our experience suggests that overlays are the main culprit.

As a side note, any new content that appears also needs to be considered for all the other requirements. Information that is not there all the time gets less scrutiny for accessibility.

Pattern-level considerations

Three of the new requirements are more relevant to page- or process-level patterns. As with the prior component-level considerations, use these quick decision trees to see if patterns in your asset libraries need further review.

4. Consistent help

A decision tree asking if help appear on more than one page. Help can be contact details such as phone, email or operational hours. It can be support such as chat, a contact form or social media, or it can be self-help, such as an FAQ or support page. If true, does the same help feature appear in different places on different pages? If true, an issue should be opened to do further review. An example is shown where a help icon appears in the header on one page and in the footer on another. — Check #4: Are help features consistently placed across pages?

3.2.6 Consistent Help requires that where you provide help mechanisms, they appear in the same location on any pages where they are used.

It is not necessary to use the same help features on all pages. Just be consistent with the placement of the feature when it appears across multiple pages.

5. Redundant entry

A decision tree asking if users are asked to provide the same information twice in a process. If true, an issue should be opened to do further review. It shows the example of an employee ID being asked for in both steps 1 and 3. — Check #5: Are users prompted to enter the same information twice?

3.3.7 Redundant Entry is intended to reduce cognitive load by not asking users to enter the same information twice. There are lots of design options to get around this, such as auto-populating, or offering the prior information in a dropdown, but the key question is “Was a user asked for the same information twice?”

6. Authentication

A decision tree asking if pasting information is prevented during authentication. If true, an issue should be opened to do further review. It shows the example of a password field with a message stating “You cannot paste text into this field.” — Check #6: Are users prevented from pasting in login information?

3.3.8 Accessible Authentication requires that users do not have to memorize, solve, or transcribe information to log in. A simple way of achieving this is to ensure that users can successfully paste information into inputs. This allows them to take advantage of password managers. It also allows them to paste in any verification codes they are sent.

Although there are other considerations in this requirement, such as not relying on most CAPTCHA tests, ensuring that the user is not prevented from pasting information during an authentication process tends to be a primary check.

For more IBM guidance on all accessibility requirements, visit www.ibm.com/able.

Michael Gower is a Senior Consultant in Accessibility in IBM Design. Illustrations by IBM Visual Design Lead Jess Lin. The above article is personal and does not necessarily represent IBM’s positions, strategies, or opinions.