So, what's new in WCAG 2.2?

Yesterday the World Wide Web Consortium (W3C) released the latest version of its Web Content Accessibility Guidelines (WCAG), which offer an internationally recognised and adopted set of recommendations to improve web accessibility and forward the goal of ensuring the benefits of the web are available to all people.

These latest changes present a smaller set of updates than the previous iteration but still offer significant developments across 9 new success criteria, including a welcome increased focus on cognitive elements of accessibility. Here we've assembled all the new additions, with a bit about what each means. Links to the full guidance are contained in the title of each standard. 

Emma's thoughts:

We're really excited to see the WCAG 2.2 standards include more focus on the cognitive elements of accessibility, which will be a big step forward for improving recognition and support for cognitive access needs.

It's also great to see motor-impairment-related needs staying in the discussion and being improved upon with 2.5.7: Dragging Movements. Those of us in web accessibility have been working with mobile apps and sites for a long time now, and it's huge to see that being reflected in the standards with more mobile gesture recognition across the new standards. Also good to see is an update to include more recent nuisances, especially:

• cookie banners
• auto-starting support chat boxes
• authentication and the rising need for 2FA as standard, which can lock out users with impairments from many vital systems if not implemented thoughtfully

Here’s what’s new:

Focus Not Obscured (Minimum) (Level AA)  

•  When you interact with a website using your keyboard, the part you're interacting with should not be hidden behind other things on the page. It should remain visible so you can see what you're doing. 

Focus Not Obscured (Enhanced) (Level AAA) 

• Similar to the first rule, this one emphasises that when you interact with a web element using your keyboard, nothing at all should hide or cover any part of that element. It should always be completely visible. 

Focus Appearance (Level AAA) 

• When you navigate a website using your keyboard, there should be a clear and visible way to indicate where your focus is. This indicator should be at least as large as the area of a 2 CSS pixel thick perimeter and have a contrast ratio of at least 3:1 between the same pixels to make it stand out from the rest of the page. 

Dragging Movements (Level AA) 

• If you want to click on something with your mouse or touch it on a touchscreen, it should be at least 24 by 24 pixels (with a few exceptions).

Target Size (Minimum) (Level AA) 

• Similar to the fourth rule, clickable things should be at least 24 by 24 CSS pixels (with a few exceptions).

Consistent Help (Level A) 

• When a website provides help options like contact information or ways to get assistance, these options should always be in the same order on different pages, unless a change is initiated by the user.

Redundant Entry (Level A) 

• If you have to type in the same information on a website more than once, like your name or email address, the website should either fill it in for you automatically or allow you to select it from a list.

Accessible Authentication (Minimum) (Level AA) 

• When you enter your password or perform actions to confirm your identity on a website, nothing should hide what you're doing with your keyboard. 

Accessible Authentication (Enhanced) (Level AAA) 

• If a website asks you to do something like solving a puzzle or remembering a complex password, they should also offer you an easier way to prove your identity that does not rely on a cognitive function rest. 

In the dynamic world of web accessibility standards, as well as the additional 9 success criteria, it's worth noting that Success Criterion 4.1.1 Parsing has been removed with the introduction of WCAG 2.2. 

This criterion was initially included in WCAG 2.0 to ensure browsers and assistive technologies could accurately process markup and content. However, advancements in web specifications and browsers, along with changes in assistive technology practices, have made this requirement obsolete. 

Today, accessibility issues that used to trigger 4.1.1 failures are now covered by other criteria like Info and Relationships (SC 1.3.1) or Name, Role, Value (SC 4.1.2). While parsing error assessment tools remain useful, they are no longer a mandatory accessibility requirement. 

It’s also important, as always, to note that this all comes with some caveats. The presentation of the guidelines themselves is not fully accessible. Martin Underhill has created a useful simplified version of each of the individual standards. The guidelines also contain nuances and exceptions, which can be found on the extended pages for each one.

We also always caution organisations that while WCAG is a good place to start, and represents a welcome international standard, the best way to reduce barriers to access for your users is to involve them, co-designing and testing your products and services with the people using them.  
 
If you’d like to learn more about accessibility and WCAG 2.2, or speak to us about how we can your organisation, get in touch with us at: hello@nexerdigital.com