Go to content
With the deadline for feedback on the WCAG 2.2 candidate Recommendation now past, let’s take a look at what designers and developers could expect.

WCAG 2.2 is, at the time of writing, two steps away from being a formal W3C Recommendation and could be ready by the end of 2022. It builds on the accessibility guidelines already set by WCAG 2.0 and WCAG 2.1, introducing nine new Success Criteria.

While the proposed requirements may still be subject to change, now is a good time to begin exploring what impact WCAG 2.2 might have on the design and development process. My hunch is the new requirements for focus styles have the most potential for tripping people up.

The existing conformance levels – A, AA and AAA – remain, each one providing a greater level of accessibility for website users. As before, the criteria are cumulative, such that Level AA is not attainable without having met all of Level A, and so on.

Most organisations and governments have decided on Level AA as the minimum legal level of conformance, so I will focus here on the Level A and AA changes.

WCAG 2.2 level A requirements

3.2.6 Consistent Help will make it easier for users to find help when they need it, by requiring help options to appear in the same location across multiple pages. Examples would include links to contact details and FAQs.

3.3.9 Redundant Entry will avoid users having to enter the same details more than once in a process, for example, an identical shipping and billing address. Forms must avoid redundant entry or make it easy for previous input to be selected.

2.4.7 Focus Visible is moving from Level AA to Level A. It requires that any user interface which can be operated via keyboard has a visible focus indicator when it receives focus.

WCAG 2.2 level AA requirements

2.4.11 Focus Appearance places a number of requirements on the appearance of focus styles, in terms of the size of the focus indicator and a minimum contrast ratio of 3:1 against adjacent colours. It also requires a minimum 3:1 contrast between the focused and unfocused states.

2.4.12 Focus Not Obscured requires that focused elements are not completely obscured by things such as sticky headers or footers, or modals.

2.5.7 Dragging Movements will ensure that users who are unable to perform an action via drag and drop, such as panning a map, have an alternative mechanism to achieve the same action.

2.5.8 Target Size (Minimum) sets a minimum required size for ‘pointer inputs’ (anything that can be clicked by a mouse or activated using a pen or by touch) unless there is a minimum distance between those inputs, to reduce the risk of users accidentally activating the input. There are exceptions for things like links within blocks of text and interactive map markers.

3.3.7 Accessible Authentication requires that authentication is possible without the need for ‘cognitive tests.’ For example, allow users to copy and paste passwords or authentication codes rather than requiring them to be manually entered, or allow users to reset their password or receive a login link via email.

Further reading

The Web Accessibility Initiative has a helpful summary of all proposed new success criteria, including Level AAA requirements and examples of how real people stand to benefit from the changes.

The article New Success Criteria in WCAG 2.2 from TPGi examines each criterion in more detail and advises on how to meet it.

I strongly recommend reading Sara Soueidan’s article: A guide to designing accessible, WCAG-compliant focus indicators.