WCAG version 2.2 will remove one guideline add nine new ones! What does that mean for us, practically? Let’s break it down.
If you’ve been keeping up with the accessibility space, then you might already know that there’s a new and updated version of the Web Content Accessibility Guidelines (WCAG) that’s been under review for the last several months. The new version will remove Success Criteria 4.1.1 Parsing and add nine new guidelines. What does that mean for us, practically? Let’s break it down:
The now-retired SC 4.1.1 had to do with parsing: writing correct and semantically valid HTML so that browsers and assistive technologies could accurately parse the information and present it to the user. Practically, that included things like ensuring that all elements have starting and ending tags, avoiding duplicate attributes, making sure any child elements were nested/ordered correctly, etc.
In general, this is (of course) still a best practice for writing code in general. However, HTML, browsers and assistive technologies have all gotten a lot smarter in the last few years and are now capable of handling errors in less disruptive ways.
For example, if you were to omit a closing tag for an element, it would likely still render in the browser. The error is (of course) not ideal, but browsers have learned how to handle and accommodate many common mistakes. They can take a “best guess” at what was intended and still load the page.
Furthermore, most assistive technologies used to do their own parsing of the HTML, which meant that mistakes like that could be incredibly disruptive. Now, it’s more common for assistive technologies to rely on the browser for that, via the accessibility tree. Since the browser has gotten smarter about parsing, that means any assistive technologies that use the browser have gotten smarter, too!
Since parsing errors will (in the vast majority of cases) no longer cause browsers or assistive technologies to crash, the WCAG has decided to retire SC 4.1.1.
Here’s a look at the nine new guidelines that have been added as part of 2.2:
Both of these guidelines have to do with ensuring that the element with focus is visible to the user. 2.4.11 is the minimum (AA) required to pass, while 2.4.12 is the enhanced, or ideal (AAA).
This guideline instructs us to create focus indicators that are easily noticeable due to their high visibility in order to achieve AAA compliance. To meet this criteria, a focus indicator must have:
The only exceptions to this are when the focus indicator is either:
This guideline is a particularly important one—especially in the era of touchscreens. We often make assumptions about how our users will interact with our interfaces, and this guideline reminds us that not everyone is capable of gesture and/or touch-based interactions.
2.5.7 states that any action that involves dragging must also offer a simple, pointer-based alternative.
Similarly to 2.5.7, 2.5.8 offers us guidance around creating target sizes for interactive elements that are easy for everyone to use and help minimize mis-clicks and mistakes.
To meet this criteria, targets for pointer inputs (such as buttons) must be at least 24 x 24 pixels,with the following exceptions. Targets can be less than 24 x 24 pixels if:
Guideline 3.2 concerns making websites predictable and intuitive for users—and 3.2.6 specifically concerns the location of help mechanisms. To comply, help tools (when available) need to be placed in the same location on every page. That could apply to chat tools, guided tutorials, contact information, or other ways for users to get unstuck when they’re confused. The actual help doesn’t need to be provided on the page (for example, it could be a link to an FAQ), but the link to the help needs to be offered in a consistent location throughout the website.
Like so many accessibility guidelines, this one is also just a polite and user-friendly thing to do: Don’t ask for the same information more than once in the same session. If the information has to be resubmitted, auto-fill and selection options are preferred. There are a few exceptions to this, though:
Finally, the last two new guidelines have to do with making it as easy as possible for users to get logged in. When we require users to do various tasks before allowing them to access the content—such as memorize information, click on photos of specific things, etc.—we’re effectively gating the content behind a cognitive function test. This puts our users with cognitive disabilities at a severe disadvantage.
Do you think they’re beneficial? Will you be implementing any right away? Let us know in the comments!
Kathryn Grayson Nanz is a developer advocate at Progress with a passion for React, UI and design and sharing with the community. She started her career as a graphic designer and was told by her Creative Director to never let anyone find out she could code because she’d be stuck doing it forever. She ignored his warning and has never been happier. You can find her writing, blogging, streaming and tweeting about React, design, UI and more. You can find her at @kathryngrayson on Twitter.
Subscribe to be the first to get our expert-written articles and tutorials for developers!
All fields are required