Recently I was reading up on what has changed in the world for web accessibility recently, and discovered that WCAG 2.1 is no longer the latest version. In October of 2023, they released version 2.2 which provides 9 new success criteria in addition to what was contained in 2.1. This update isn’t just a bunch of new rules; it’s about making sure the web stays open for all.

I want to address some of the accessibility challenges we continue to face, as revealed by this new update, and why these things might be important.

But first, a quick reminder about the Guidelines, and what exactly is “success criteria?”

What does “success criteria” mean?

When it comes to WCAG, it’s important to understand the distinction between the Guidelines and the Success Critera.

In short, the Guidelines are the “rules” of accessibility - i.e., what are the actual standards; the Success Criteria provides tangible examples, tasks, or checklists of specific things that can help one to achieve success according to the guidelines. They are the “techniques” to achieve success, as it were.

For a quick overview of the guidelines, take a look at this post from a few years ago.

WCAG 2.2 came out with 9 new success criteria late last year, which help to deal with the ever-evolving landscape of the web. As new technologies emerge with new types of interactions, the success criteria need to evolve as well.

Just think for a minute about how our use of the internet has changed since the guidelines were first produced. For example, we now have touch devices, as well as new and advanced interactions like swiping; even in the realm of traditional screens, dragging things from one column to another is a relatively new invention, which is accounted for in these new criteria. With this in mind, it’s easy to see why new success criteria might be necessary to evaluate the accessibility of our projects.

Without going into great detail, let’s take a quick look at the new items.

New Success Criteria

Here is the list of new items for your reference:

• 2.4.11 Focus Not Obscured (Minimum) (AA)
• 2.4.12 Focus Not Obscured (Enhanced) (AAA)
• 2.4.13 Focus Appearance (AAA)
• 2.5.7 Dragging Movements (AA)
• 2.5.8 Target Size (Minimum) (AA)
• 3.2.6 Consistent Help (A)
• 3.3.7 Redundant Entry (A)
• 3.3.8 Accessible Authentication (Minimum) (AA)
• 3.3.9 Accessible Authentication (Enhanced) (AAA)

Upon reviewing the nine new success criteria and what they actually mean, something stood out to me: we continue to struggle with the same issues—focus indicators and keyboard navigation.

The Big Issue: Operability - Focus and Keyboards

The first five items in the list fall under Guideline 2 of WCAG - “operable” - can we actually use the website in a reasonable fashion?

It’s an ongoing battle to convince designers who have accessibility blinders on to not remove focus states from their designs. I don’t know what the metrics are around how many websites remove the focus outline from links or form controls, but I remember well the days when there were complaints about the blue rings around buttons or links on the basis of aesthetics.

So why keep them? Keyboard-only users absolutely rely on focus rings in order to know where they are in the webpage. Indeed, the keyboard for many people serves as, or even replaces, the mouse pointer.

I should point out that it’s not just hardcore Vim users who never touch the mouse — how many people do you know who have a temporary disability, like a broken arm or a shoulder sprain? For them, it’s much easier to tab around a website with the left hand on the keyboard, assuming one is right-handed, than it is to use the mouse with the left hand. Food for thought.

Again keeping these folks in mind, let’s look at the “dragging” interaction mentioned above. How pervasive is this now? Even just in tech, we see this all over the place: Trello, Jira, Notion, or any type of kanban-style drag-and-drop interface. How hard would these be for someone who can’t even use a mouse effectively?

The 2.5.7 “dragging movements” new success criteria suggests there needs to be some sort of alternative. Could the keyboard be leveraged with arrow keys to enable these movements from one zone to another? Or, could buttons be exposed to select which column a card item should be moved to?

Accessibility and the future

As we develop new sites, apps, and products on the web, not only is it wise to think about such users; accommodating them is becoming a legal requiremnt in many jurisdictions. In the United States, the Americans with Disabilities Act (ADA) has web accessibility requirements; in Ontario, the Accessibility for Ontarians with Disabilities Act (AODA) likewise upholds WCAG in the eyes of the law.

In other words, this stuff is no longer a nice-to-have feature “if we have time or budget.” Rather, ignoring accessibility in web projects can expose one to liability and lawsuits. Indeed, this has already happened in many places, to the tune of hundreds of thousands, even millions of dollars. Take responsibility - don’t let it happen to you!

Looking at WCAG 2.2’s updates, it’s clear: making the web accessible is an ongoing mission. These changes target specific new UI patterns to keep up with our ever-evolving digital world. For anyone building or managing websites, adopting these guidelines isn’t just about dodging legal bullets—it’s about making sure the web works for everyone. Because when the web’s open to all, we all win.

Learn more about the latest details of WCAG 2.2 from the W3C Web Accessibility Initiative website.

Do you need help making your site more accessible? Reach out, I can help you get started.

I need help!