A whistle stop tour of WCAG 2.2

Firstly, here’s the story so far: The very first version of the Web Content Accessibility Guidelines (WCAG) was published in 1999. It was a game changer. Suddenly, there was a set of specific standards that helped to make the web more accessible, and when WCAG v2.0 was released, they quickly became the gold standard for accessibility. WCAG 2.1 continues this legacy and is still considered the gold standard. Don’t get us wrong, there are many challenges with interpreting and using these guidelines, but even today, in conjunction with inclusive design and testing, they are an essential tool in making more accessible digital products.

A lot has changed since they were first released, and the guidelines are now on their third version (WCAG 2.1), with two other versions (WCAG 2.2 and WCAG 3.0 – Silver) currently in development. On 13 May 2020, the latest working draft of version 2.2 of the Web Content Accessibility Guidelines (WCAG) was published for feedback. This working draft has one change to an existing success criterion and nine new success criteria that are still in active development (so they may or may not make it to the final recommendation as they are). This version still follows the structure of WCAG 2.1, and includes the same conformance levels (A, AA and AAA).

So, here is our simplified interpretation of the new proposed WCAG 2.2 success criteria, grouped by their conformance levels.

A level criteria:

1. WCAG 2.4.13 – Page Break Navigation:

This is most applicable to ‘electronic publications’ (ePUB) and other similar formats (like PDF documents). It involves ensuring that page break locators and page numbers remain within the same relative location in the content even after assistive technology users make adjustments to the way the pages are displayed. This makes it possible for all users, irrespective of how they view/interact with the content, to find a particular page and have the same start and end content as everyone else.

2. WCAG 3.2.6 – Consistent Help:

Access to help is important for all users, and so this aims to make it easier to navigate to help features (e.g. contact information or FAQs) by placing these features in the same relative place across the website. For example, if a link to contact information is in the header of a web page, then it must be placed consistently in the header of all pages within the website.

3. WCAG 3.3.7 – Accessible Authentication:

This aims to provide an accessible, easy and secure way to log in. It requires that authentication must be possible without cognitive tests, so that there is no reliance on memorising passwords or transcribing codes sent by text or email. An example of how this can be achieved is to support password entry through password managers and ensuring copy and paste is possible so that manual entry can be avoided if needed. This is particularly useful for people with certain cognitive issues relating to memory, reading (e.g. dyslexia) and numbers (e.g. dyscalculia).

4. WCAG 3.3.8 – Redundant Entry:

Text entry is generally tedious for all, but for some users it is downright difficult. This aims to minimise having to re-enter data that was previously provided within the same process or in the same session by auto-populating or providing an option to select. For example, enabling the user to confirm that the billing address and delivery address are the same (rather than asking them to type each one out). This is particularly useful for users with cognitive issues and those with upper limb mobility impairments.

AA level criteria

5. WCAG 2.5.7 – Dragging movements:

This requires that dragging movements are not the only way certain actions can be achieved. It aims to ensure that people with motor impairments who find drag and drop type precise movements tricky, can use all functionality by providing an alternative. For example, in addition to being able to pinch and pull to zoom in/out of a map, provide separate buttons to zoom in and out.

6. WCAG 2.5.8 – Target size (minimum):

We all know the challenge of selecting small targets, especially when they are placed close together (think back to trying to make selections on your phone during a particularly bumpy car ride – not fun). This is even trickier for those with certain upper limb mobility impairments, like hand tremors. To overcome this challenge, this success criterion requires that most targets (with some exceptions) be placed within a 24×24 pixel area that must not include any other targets.

(Note: using larger sizes will help many people use targets more easily. Meeting 2.5.5 Target Size (Enhanced) is recommended whenever possible).

7. WCAG 3.2.7 – Visible Controls:

In most situations, no one wants to spend time looking for controls. This success criterion requires that all active controls be persistently visible (and does not require pointer hover or keyboard focus to make them visible). This is particularly useful for people with impaired memory or certain other cognitive and learning disabilities, as it ensures that they can easily find the right controls.

8. WCAG 2.4.11 – Focus Appearance (Minimum) AA level:

This aims to ensure that the keyboard focus indicator is clearly visible and obvious. It achieves this by defining a minimum area for the indicator as well as requiring sufficient contrast between the focused and unfocused states of elements. The element in focus must also not be entirely hidden. It is particularly relevant to sighted keyboard-only and keyboard-like device users (e.g. a switch or voice input) as it helps them more easily identify where the focus indicator is (and thus which element they could interact with).

AAA level criteria:

9. WCAG 2.4.12 – Focus Appearance (Enhanced):

This is the only AAA level criterion and adds on to the previous success criterion (WCAG 2.4.11) by requiring a higher level of visibility for the focus indicator.

It achieves this by increasing the size and contrast ratio of the indicator and requiring that no part of the indicator be hidden. As before, it is relevant to sighted keyboard-only and keyboard-like device (e.g., a switch or voice input) users.

…and one last change:

10. WCAG 2.4.7 – Focus visible:

This is an existing success criterion that was first introduced in WCAG 2.0, and so is well-established. It requires that the keyboard focus indicator be visible, which makes it possible for users to know which element has keyboard focus (and so, what they are interacting with). In WCAG 2.2, it is proposed to upgrade this criterion from conformance level AA to A.

We are very pleased to see that the new success criteria consider a wider range of needs, for example, those with cognitive and upper limb mobility impairments as well as those who use alternative input devices. So, we are delighted with the new success criteria, though we feel that some of them need a bit more clarification before they can be practically applied. We have no doubt that they will ultimately make the guidelines more encompassing and helpful in making digital content more accessible to a wider audience.

That’s it for now! We will be closely monitoring and contributing our feedback as these guidelines evolve and will keep you updated.