Understanding WCAG 2.2

Since its release on Oct 5, 2023, WCAG (Web Content Accessibility Guidelines) 2.2 has offered 9 new recommendations for building a more accessible web. It came as a welcome update, 5 years since the last WCAG 2.1 release. 

With about half of the new content having a focus on helping those with cognitive, language, and learning disabilities, this latest release provides some much needed recommendations useful for developers looking to improve the accessibility of their websites and apps.

In this post, we’ll go through the new success criteria, and provide some suggestions on how to best meet them.

2.4.11 Focus Not Obscured (Minimum) (AA) and 2.4.12 Focus Not Obscured (Enhanced) (AAA)

Imagine trying to use a website with a mouse, but the pointer is invisible. It’d get frustrating pretty quickly right - and that’s the reality for sighted users who rely on non-mouse assistive technologies, like keyboard, an ability switch, or voice input when navigating websites that don’t meet the WCAG Focus Not Obscured criteria.

These criteria require all user interface components such as form inputs, buttons and links to be at least partially visible (AA) or completely visible (AAA) upon receiving keyboard focus. Focus indicators can commonly get obscured by author-created content, such as popup dialogs, sticky headers/footers or cookie banners, which can make navigating via a keyboard really tricky. Keyboard users need to be able to see which element is currently focused, to know where they ‘are’, and WCAG criteria 2.4.11 and 2.4.12 aims to improve that.

2.4.13 Focus Appearance (AAA)

Smaller changes in the visual appearance of a focused element can be easy to miss, especially for people with visual impairments. This criteria’s focus is improving the visibility of a focus indicator by ensuring it displays with a sufficient size and colour contrast ratio. 

In order to meet WCAG’s highest level of compliance you’ll need to ensure all focus indicators are at least as large as a 2px thick perimeter of the unfocused target, which can be met simply by having a 2px outline on target focus. 

In addition to the perimeters size, the focus indicator must also meet the minimum contrast ratio of 3:1 - the same contrast ratio specified in 1.4.11 Non-text Contrast (AA) - aiming to ensure that the focus indicator will stand out sufficiently against its background colour.

2.5.7 Dragging Movements (AA)

Dragging can be a complex gesture for those who have difficulty with fine motor control, and a straight up challenge for those using specialised input devices like head pointers or speech-controlled mouse emulators. Much like WCAG criteria 2.5.1 Pointer Gestures introduced in WCAG 2.1, Dragging Movements (AA) encourages developers and designers to offer alternative methods of interaction that don’t rely on a dragging gesture.

This criteria requires that all functionality that uses dragging (an operation where the pointer engages with an element on the down event and the element follows the pointer until an up event), can be achieved by a single pointer, such as a mouse click, or a finger on a touch screen. An example of providing alternative functionality to meet this criteria would be adding arrows to move you to the previous or next element of a carousel or slider with a single click.

2.5.8 Target Size (Minimum) (AA)

Have you ever tried to click a teeny tiny link on your phone, only to click a different link right next to it? You might start to feel self conscious about the size of your fingers, but despair not! It’s not your phalanges at fault, but the target size of the link. 

For able-bodied people, this can be very frustrating, but to those who struggle with fine motor control, it’s a legitimate barrier to access. Criteria 2.5.8 requires all targets that accept a pointer event (like a click) be at least 24px wide by 24px high in size. 

This was added to supplement its AAA equivalent, criteria 2.5.5 Target Size (Enhanced) added in WCAG 2.1, which requires targets to be at least 44px wide by 44px high. There are a few exceptions to this rule, such as if the target appears inline and is constrained by the line-height of its parent, but all in all, it’s great to see a AA criteria for target size in this WCAG version.

3.2.6 Consistent Help (A)

An important aspect of accessible web design and development is the concept of consistency across multiple pages. Imagine you’re navigating a website and the position of the main menu changed between pages. You’d have to go searching for it each time just to find the information you’re looking for… a pretty poor experience right? Well, the main navigation isn’t the only piece of important information that should be consistently located, and that’s what criteria 3.2.6 consistent help is trying to address.

If a website contains the following help mechanisms and they repeat across multiple pages, criteria 3.2.6 requires that the mechanisms occur in the same order relative to other page content by default. 

These help mechanisms are:

• Human contact details

• Human contact mechanism

• Self-help option

• A fully automated contact mechanism

For example, if your website has contact details in the footer on the homepage, in the sidebar for the about page, below the hero on the services page etc, you would need to move them to a consistent spot in order to meet this criteria. Consistency helps a user to predict where content will be, even for pages with different layouts. 

3.3.7 Redundant Entry (A)

No one likes having to tediously re-enter content they’ve already provided in a form or a profile, and for some people with cognitive disabilities, it can be difficult or impossible to remember what they entered before. This could represent a significant barrier to users in completing multi-step tasks.

Criteria 3.3.7 Redundant entry aims to make it easier for users to complete multi-step processes without requiring short-term working memory, by requiring information to not have to be input more than once within the same activity. If information is required again, it should be either pre-populated, or available for the user to select. There are a few exceptions, such as when re-entering content is crucial for ensuring the security of the content.

3.3.8 Accessible Authentication (Minimum) (AA) and 3.3.9 Accessible Authentication (Enhanced) (AAA)

Are you sick of clicking the squares that contain buses, or solving a math question to prove you’re not a robot? Authentication processes that use cognitive function tests such as solving puzzles or remembering passwords may be difficult or impossible to complete for users with cognitive disabilities.

Both criteria 3.3.8 and 3.3.9 require either an alternative authentication method that does not rely on cognitive function tests to be provided, or a mechanism to be made available to assist the user in completing the cognitive function test. An example of the latter is supporting password managers to allow entering usernames and passwords without relying on memory.

It’s worth noting that the AA level of compliance still allows cognitive function tests in the form of:

• personal content - identifying user provided non-text content such as images, and emoticons.

• object recognition - sorry bus square haters.

Conclusion

WCAG 2.2 has added some much needed improvements to the guidelines, especially for those with cognitive impairments. It is great to know that the specification continues to grow and adapt to an ever-changing landscape to help facilitate a more accessible web.