Nice to Meet You, WCAG 2.2
The Web Accessibility Initiative (WAI) is working on developing new accessibility standards all the time. One of the most important ones right now is the Web Content Accessibility Guidelines (WCAG) version 2.2.
WCAG 2.2 is Coming Soon
Accessibility legislature around the world requires compliance with the WCAG 2.1 – the most up to date guidelines that are currently out about web accessibility, but the WCAG 2.2 is expected to be finalized and published by the end of 2022. While the changes aren’t drastic, there are nine additional success criteria from version 2.1 which were worth publishing an entirely new version of the WCAG, and it’s important to understand why. The WCAG 2.2 will likely replace the WCAG 2.1, so it’s time we get to know and understand its new features.
The WCAG 2.2’s Status
If you missed the first part in this series, it talks about the WCAG’s publishing process in depth, so you may want to catch up on it now. But the WCAG 2.2 has just moved to the Candidate proposal stage as of September 6th, 2022, which means that no more substantive changes are likely to be made, and we can assume its final version will look very similar to how it does now. It also means that we should begin to put its recommendations into practice.
As of the current working draft, there are 9 new success criteria in the WCAG 2.2 from the WCAG 2.1[i]. All versions of the WCAG have different levels of success criteria, the highest being AAA, then AA, then A. Level A is considered the minimal level of accessibility that web content can have, and AAA is acknowledged to be impossible to meet in some cases. Level AA is what's required by most accessibility legislature that uses the WCAG as a standard.
In addition to the 9 new success criteria, there is one change to an existing guideline from WCAG 2.1: guideline 2.4.7 Focus Visible has been downgraded from level AA in WCAG 2.1 to level A in WCAG 2.2. This guideline specifies that there should be a visible focus indicator for the purpose of keyboard navigation, but it doesn’t specify what qualifies as “visible.” Luckily, WCAG 2.2 has new success criteria that address that. The first, on Level AA, is guideline 2.4.11 Focus Appearance, which gives a minimum size, shape, and color contrast between the focus indicator and the unfocused area surrounding it[ii]. Color contrasts can be measured in an objective way, and the areas are given relative to pixels, which makes it easier to measure whether a given piece of web content has met the requirement.
The second is guideline 2.4.12 Focus Not Obscured (Minimum), on level AA. It says that when an element of the user interface (UI) has keyboard focus, it shouldn’t be entirely obscured by author-created content. The third guideline, 2.4.13 Focus Not Obscured (Enhanced), is the level AAA counterpart. It states that any element of the UI with keyboard focus should be completely unobstructed by author-created content. In a previous draft, these three guidelines about the keyboard focus were two clunky ones where the only significant difference was the degree to which the focused element could be hidden; expanding them to three simpler ones is a credit to the working group’s editing process.
Guideline 2.5.7 Dragging Movements states that all functionality that involves dragging an element of the user interface from one place to another can also be done without the dragging motion. This is meant to assist users with mobility impairments. Guideline 2.5.8 Target Size (Minimum) states that targets of pointer input (i.e., anywhere a user would use a mouse, stylus, touch, etc.) must be of a certain size, and it allows for exceptions based on the type of target it is (for example, if it’s part of a line of text).
The above criteria are all related to operability. The rest of the new success criteria in WCAG 2.2 relate to understandability. Guideline 3.2.6 Consistent Help (Level A) states that if certain user help mechanisms exist on a series of pages, they must be displayed in the same relative order across all the web pages that include them.
Guideline 3.3.7 Accessible Authentication (Level AA) states that authentication processes (like logging in) shouldn’t include what are, in essence, cognitive function tests, such as solving puzzles or remembering passwords, as a step in that authentication. It must provide alternative options to the test or ensure that there’s a mechanism available to help the user (like password managers and copy-paste options). Exceptions allow cognitive tests if the test is object recognition or the test is to identify non-text personal information provided by the user. Guideline 3.3.8 Accessible Authentication (No Exception) is on Level AAA, and it’s the same as the last one, but it doesn’t include the exceptions for object recognition or personal information.
The last new success criterion in WCAG 2.2 is guideline 3.3.9 Redundant Entry. It states that information that the user has already entered or received should be provided for the user to select or automatically populated if it needs to be entered again as part of the same process. It allows exceptions for when re-entering the information is deemed essential, when it’s required for the content’s security, or if the previously entered information is no longer valid.
The Importance of Keeping Up with Standards
As with version 2.1 to version 2.0, content that conforms with WCAG 2.2 will also conform with version 2.1 and therefore version 2.0 as well. The WCAG 2.2 will likely be adopted by legislatures around the world eventually, with the European Standards Organization (ESO) ETSI already reviewing the working drafts to incorporate into the next European accessibility legislation, as can be seen in their working group[iii]. When it will be adopted into Section 508 of the ADA is a question, but it’s likely that non-governmental American institutions will adopt it first, and it will become inevitable for policy to catch up at some point.
It’s essential that accessibility standards are upkept at the same rate that technology develops – fast. Without mainstream awareness or policy enforcing it, accessibility would be entirely left by the wayside and the inequities that keep people with disabilities on the margins of society would only intensify if not for standards like the WCAG. But it’s also important to remember that the WCAG, or any version of it, is just one interpretation of what it means for content to be accessible (albeit a very thorough and well-researched one). Conforming to the WCAG 2.1, 2.2, or 3.0 when it comes out, will still not guarantee 100% accessibility, just 100% compliance. Accessibility is about people, who are constantly evolving with changing needs. Removing barriers as much as possible is the best approach, and ultimately, it is listening to people with disabilities and their self-determined needs that will create accessible spaces.
[i] The upcoming changes mentioned in this post are based on the editor’s draft of the WCAG 2.2 published on August 26th 2022.
This may also interest you
How We Got into Digital Accessibility and Why It’s So Important to Us
How SenseIT CATS Creates a Better User Experience (UX)
Keyboard Navigation Functionality Testing Explained