It’s been a long time coming, but the Web Content Accessibility Guidelines (WCAG) version 2.2 is nearly here! No, really, we mean it this time. On July 20, WCAG 2.2 moved to the W3C Proposed Recommendation stage. A proposed recommendation means that W3C has accepted it, and W3C members will now vote on publishing the document as a W3C Recommendation. While the voting ends on August 19, 2023, and the hope is it will be ready to publish shortly following that, it’s important to note that the W3C members’ input during the voting process could require more work to be done. The plan, however, is by the end of August, we will indeed have a new update to WCAG.
What are the Changes?
WCAG 2.2 builds on WCAG 2.1 just as WCAG 2.1 built on 2.0 and extends WCAG 2.x series of guidelines. It includes all of WCAG 2.1, minus 4.1.1 Parsing (more on this later), plus nine new criteria. Of those, two are Level A, four are Level AA, and three will be Level AAA Success Criteria (SC).
Most organizations are aiming to meet WCAG to Level AA, meaning they will be adding six new criteria to their list. As the new success criteria will be additions to the existing guidelines, it’ll keep existing backward compatibility and the same conformance model.
Much like the 2.1 added criteria, these will aim to help users with low vision, cognitive and learning disabilities, and those with motor disabilities with benefits for users that have disabilities on mobile devices.
New Success Criteria
Let’s break down what each of these new SC, their names, levels and what the impact is for end users.
Guideline 2.4 Navigable
Under Guideline 2.4 Navigable sits three of the new SC. Here we find 2.4.11 Focus Not Obscured (Minimum) a Level AA criterion. For people who rely on a keyboard or a keyboard-like device, knowing the current point of focus is important. This new criterion says if other content overlaps with a focused item, the focused element cannot be hidden.
Typical types of content that can overlap focused items, causing an accessibility issue, are sticky footers or headers. When a user tabs through the page, a sticky footer, for example, hides parts of the focused item.
2.4.12 Focus Not Obscured (Enhanced) is the Level AAA version of the previous one and simply says when tabbing down the page, the focused item is not overlapped by other content at all.
The other SC sitting under the Navigable Guideline is 2.4.13 Focus Appearance. There has been much chatter about this one, and it’s changed a few times during the draft stages, but the Working Group believes they have found the right balance now.
The debate and, indeed, the inconsistency of how visible focus for keyboard focus indicators is determined as accessible or not has been ongoing for, well, honestly, as long as I have been in the industry (which is 10 years). While it sits as a Level AAA, this new SC finally ends any debate, and honestly, it’s a very welcome addition!
Most importantly, this success criterion will have colour contrast ratios will be taken into account. When indicating focus, you will need to have at least a 3:1 contrast ratio and a minimum of 2 CSS pixel perimeter. This will help ensure keyboard users can easily see which interactive element has focus.
Guideline 2.5 Input Modalities
Input Modalities has two new SC added to it with Dragging Movements and a Level AA version of Target Size.
2.5.7 Dragging Movements is pegged to be a level AA criterion which will ensure dragging movement can be operated by a single pointer without dragging, of course, unless dragging is essential. It is similar to pointer gestures which talks of directional path-based and multi-point gestures. The difference here is the definition of what is a dragging motion. With dragging, only the start and end point of the motion matters, not the path. The concept is the same, though, and this is a good assurance that alternatives are available for users who are unable to drag either at all or accurately.
2.5.8 Target Size (Minimum) is another AA-level criterion. Here the intention is to make sure targets like buttons or linked icons can be easily activated without accidentally activating a nearby target. Providing sufficient size and/or spacing between targets will reduce the likelihood of accidentally activating the wrong control. The requirement here is target sizes are at least 24 by 24 CSS pixels. This can include white space around the target.
Guideline 3.2 Predictable
One SC is added to the Predictable Guideline in 3.2.6 Consistent Help, which says if help options are available, think: chat, contact details for a person, or a self-help option, for a set of pages, then access to at least one option is included in the same relative order on each page of that set.
Meaning if you have a chat option, it should be easily found in the same place on every page in the journey, like pinned to the bottom right-hand corner making help options easy to find. This will be a Level A requirement.
Guideline 3.3 Input Assistance
There are a few great additions to Input Assistance. Here we find a significant focus on considering cognitive load in relation to filling in forms and authentication.
Let’s start with 3.3.7 Redundant Entry, which is slotted to be a Level A criterion. When filling out a form where there is a request for data that had already been entered earlier in the form, repeated data will need to be available through autofill or able to be selected. This reduces cognitive effort when information is asked for more than once during steps in a process. It also reduces the need to recall information provided in a previous step. There are exceptions here for confirming passwords and abandoned forms.
3.3.8 Accessible Authentication (Minimum), a Level AA criterion, says that a cognitive test should not be required in an authentication process. Good news for biometrics! Don’t panic; you can still utilize username (or email) and password inputs as an authentication method as long as browsers and password managers are not blocked and can be used to fill in the fields automatically or you allow for copying and pasting to reduce the cognitive burden of re-typing.
3.3.9 Accessible Authentication (Enhanced) is level AAA is the same as the above Minimum version but without exceptions for object recognition and user-provided content. So again, it’s meant to ensure there is an accessible, easy-to-use, and secure method to log in, access content etc.
What about Parsing?
For the first time in the WCAG 2 series, the Working Group has determined a SC to be obsolete and removed 4.1.1 Parsing. There are a couple of factors taken into consideration around this decision.
The Working Group has concluded that any real issues impacting users with disabilities which would be caught in 4.1.1 would/should be otherwise caught by other success criteria like 1.3.1 Info and Relationship or 4.1.2 Name Role Value. The other parsing issues which commonly occur, it was felt, do not create accessibility errors anymore based on how today’s browsers and assistive technologies render the code.
It is worth pointing out that Parsing sat under the robust principle in WCAG. Robust focuses on ensuring that the web content is compatible with different technologies and assistive devices. This involves using coding and web development practices that support accessibility features and can be used by a variety of user agents.
Now there are a couple of talking points for this one, and it’s caused some robust (pun intended) conversations. A couple of my thoughts on this one:
- Failing Parsing is holding up organizations from claiming conformance; however, if it doesn’t have any real-world impact – is that a good use of anyone’s time?
- WCAG 2.2 is meant to remain backwards compatible, but there is still a lot of grey area around how it would work for WCAG 2.1 and 2.0 and dated standards used by law and governing bodies internationally. This is not unsolvable, but it does need some more thought and discussion. The Working Group is already considering this, but it’s worth the mention until a solution is found.
- I’ve always used the analogy that we don’t create new technology, assistive or otherwise, based on rubbish code (or alphabet soup as I like to call it), so by losing parsing, are we lowering the HTML standard all around?
- Are we making assumptions about how many AT users keep browsers and their AT updated and current? Is this an example of focusing too much on North American or European statistics around AT usage?
Supporting Documents
The Working Group continues to create techniques that will document sufficient and failure examples for the WCAG 2 series of guidelines, with emphasis placed on creating techniques for the new criteria in WCAG 2.2. Additional supporting documents, including How to Meet WCAG 2.2 and Understanding WCAG 2.2, are available for review now.
Future Versions
Finally, there is unlikely a WCAG 2.3; however, as I learned long ago, never say never. Following the release of version 2.2, it’s expected the majority of the Working Group’s effort will be put into a future version of accessibility guidelines, like WCAG 3.0 or Silver, as it’s still known in some accessibility circles. 3.0 will be a significant successor revision of WCAG guidelines and will not be backwards compatible. This, however, is still years away, making everyone’s understanding of 2.2 a high priority for now and in the near to medium future.
