A summary of WCAG 2.2 and how it may impact your product.
Web Content Accessibility Guidelines (WCAG) 2.2 was published as a W3C Recommendation
web standard on October 5, 2023.
According to the World Wide Web (W3) site:
WCAG 2.2 was initiated with the goal to continue the work of WCAG 2.1: Improving accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices.
This is huge news for anyone who creates websites, digital services, or mobile applications, or if you simply care about making the internet more accessible in general.
WCAG 2.2: what’s new
WCAG 2.2 retains the majority of WCAG 2.1 (78 success criteria). WCAG 2.2 adds 9 new criteria and removes one, WCAG 4.1.1 Parsing, so in total it has 86 success criteria.
In regards to success criteria 4.1.1, Parsing
W3 states:
This criterion was originally adopted to address problems that assistive technology had directly parsing HTML. Assistive technology no longer has any need to directly parse HTML. Consequently, these problems either no longer exist or are addressed by other criteria. This criterion no longer has utility and is removed.
6 of the 9 new criteria fall under the A and AA levels, which are the ones that most people pay attention to. Here is a short overview table of the new criteria, their levels, and who will gain the most from them.
| Success Criteria | Benefits | ||||
|---|---|---|---|---|---|
| ID | Name | Level | Cognitive | Fine Motor | Low Vision |
| 2.4.11 | Focus Not Obscured (Minimum) You must not let anything fully obscure the element that has keyboard focus. | AA | Supported | Supported | Supported |
| 2.4.12 | Focus Not Obscured (Enhanced) The focus indicator must always be fully visible. | AAA | Supported | Supported | Supported |
| 2.4.13 | Focus Appearance Defines what a visible indicator must look like, both in terms of size and overall area, and what the difference in contrast must be between an element’s focused and unfocused states. | AAA | Supported | Supported | Supported |
| 2.5.7 | Dragging Movements If something can be dragged, make sure there is an alternative interaction that can be accomplished with a single click, which will also work when using only a keyboard. | AA | Supported | ||
| 2.5.8 | Target Size (Minimum) Clickable elements need to be at least 24px by 24px in size. | AA | Supported | ||
| 3.2.6 | Consistent Help On each page, keep your support options in the same location. | A | Supported | ||
| 3.3.7 | Redundant Entry Users should not be asked multiple times to re-enter information they have already provided as part of the same process. | A | Supported | ||
| 3.3.8 | Accessible Authentication (Minimum) Accessible Authentication must avoid authenticating users through memory, transcription, or cognitive tests without alternatives. | AA | Supported | ||
| 3.3.9 | Accessible Authentication (Enhanced) All inputs used in authenticating a user should support copying and pasting values, so include autocomplete on inputs and allow password managers to store and retrieve passwords and credentials for a service. | AAA | Supported | ||
Summary
The W3C’s Web Content Accessibility Guidelines (WCAG) 2.2 represent an evolution of previous accessibility standards. It improves on and expands on the guidelines established in WCAG 2.1.
WCAG 2.2, released to adapt to the ever-changing digital world, includes new success criteria and enhancements. It ensures that web content is accessible to people with disabilities, taking into account developing technology and the larger needs of users. The update prioritizes users with various cognitive impairments, as well as better mobile accessibility and clarity for developers and content providers.
Use automated tools to perform a digital accessibility audit and test the digital properties for accessibility issues. These tools can help identify common accessibility barriers, such as missing alternative text for images, improper heading structure, and keyboard navigation issues.
Comments