WCAG 2.2 is Here

In May of 1999, the Web Accessibility Initiative, working under the World Wide Web Consortium (W3C) established the WCAG, a set of guidelines aimed at making the web usable for everyone regardless of their impairments or circumstances. Its founders believed the internet was a new frontier capable of bringing people together and helping them access information in unprecedented ways. They understood that liberties needed to be taken to ensure no one was left out of this digital revolution.

Fast forward nearly 25 years later to 2023, these standards continue evolving to support new technologies and practices.

The latest release, WCAG 2.2, became an official recommendation on October 5, 2023.

In this update, we’ll delve into the history of WCAG, what’s new, and what you need to know to stay up to date.

For reference, here’s the latest version of the guidelines.

The Evolution of WCAG

To stay relevant amid ever-changing trends, practices, and user requirements, the WCAG has undergone a few revisions. Version 2.2 marks the fourth version. Here is a brief timeline of the changes it builds upon

• WCAG 1.0 (May 1999): This was the starting point, introducing the concept of web accessibility and laying out basic requirements mainly focusing on content written in HTML.
• WCAG 2.0 (December 2008): A major leap forward, this version defined the four categorical operating principles we use today (perceivable, operable, understandable, and robust). Importantly, it extended its reach to cover all digital content–not just that written in HTML.
• WCAG 2.1 (June 2018): With the rise of mobile devices, WCAG 2.1 added 17 additional success criteria. It also enhanced support for people with low vision and addressed some common cognitive challenges.

What’s Changing in WCAG 2.2

Now, let’s take a closer look at the changes WCAG 2.2 is bringing to the table. It will be parting ways with one success criterion and introducing nine new ones, making a grand total of 86 success criteria.

There were originally plans to elevate 2.4.7 Focus Visible from level AA to level A, but this proposal was eventually shot down.

Below, we briefly summarize each new requirement in as much detail as possible with the intent of maintaining brevity. There are often edge cases, exceptions, and considerations to be aware of. For more information and guidance on meeting criteria, feel free to click on any of the linked “understanding WCAG” documents.

Removal of SC 4.1.1 – Parsing

This criterion was originally adopted to address problems that could arise when assistive technology wasn’t able to interpret HTML, creating an inconsistency between what was shown in the browser and what was presented to users. These days, all needed information is gathered from the browser itself and communicated via the accessibility tree. As such, any user impact is adequately covered by other SCs, like 1.3.1 Info and Relationships.

SC 2.4.11 Focus Not Obscured (Minimum)

Level AA

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

This new success criterion emphasizes that elements that receive focus from the keyboard must remain at least partially visible to users at all times. It addresses challenges posed by responsive design patterns that have seen increased popularity, i.e sticky footers, sticky headers, notification banners, and non-modal dialogs that temporarily blur or obscure the focus indicator.

As an example, consider a site that adds a cookie consent pop-up (not a modal) to meet GDPR requirements. This pop-up is only shown once everything else has loaded. So a low vision user is tabbing through the navigation links on the page, but is bombarded with this request which populates the viewport and swallows any indication of their previous position.

In short, UI controls that overlap with other components cannot entirely obscure the item with focus.

SC 2.4.12 Focus Not Obscured (Enhanced)

Level AAA

When a user interface component receives keyboard focus, no part of the component is hidden by author-created content.

This is effectively 2.4.11 as covered previously, except it does not allow any part of the focused element to be obscured whatsoever, omitting other allowances for content that can be dismissed.

SC 2.4.13 Focus Appearance

Level AAA

When the keyboard focus indicator is visible, an area of the focus indicator meets all the following: • is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states. Exceptions: • The focus indicator is determined by the user agent and cannot be adjusted by the author, or • The focus indicator and the indicator’s background color are not modified by the author.

This success criterion aims to make it easier for users to locate and see the focus indicator by defining a minimum size and contrast ratio. Additionally, these indicators must have a discernable change in contrast between focused and non-focused states. Modern browsers automatically supply a visual outline for the item that currently has focus, which passes this requirement. However, oftentimes the default indicator conflicts with custom designs, making it difficult to see against low contrast backgrounds. In this case, ensure that there is a solid outline with high contrast surrounding whichever item currently has the focus.

SC 2.5.7 Dragging Movements

Level AA

Functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

Whenever a process such as drag-and-drop, zoom in, line drawing, etc. requires dragging movement, there should be an alternative. Dragging movement involves pressing down on a mouse or touch screen, holding the button, dragging to a position, and then releasing at the new location. Users who have hand tremors, strength limitations, or who need to navigate with eye gazing/tracking technology will find this cumbersome at best and impossible at worst. Passable alternatives will need to take into account both keyboards and touch screens.

One thing worth noting is that this requirement only applies to your web content. For instance, it is not a failure if assistive technology or the browser itself relies on dragging. There are other standards for information and communication technology (ICT) that would be more applicable for such a situation.

SC 2.5.8 Target Size (Minimum)

Level AA

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where: • Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target; • Equivalent: The function can be achieved through a different control on the same page that meets this criterion; • Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text; • User agent control: The size of the target is determined by the user agent and is not modified by the author; • Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

The size of the target for a control, or the area where it can be clicked, must meet minimum size requirements or have sufficient spacing surrounding it.

Due to limitations with dexterity and fine motor control, certain users may not be able to click on small items that are close together, as doing so requires extreme precision. Failure often leads to scenarios where it is difficult or impossible to select targets. Occasionally–if a different target is too close or assistive technology is not accurate enough–these users will even be forced into inadvertently activating the wrong thing.

If a minimum size is not possible, this SC requires adequate spacing.

SC 3.2.6 Consistent Help

Level A

If a Web page contains any of the following help mechanisms, and those mechanisms are repeated on multiple Web pages within a set of Web pages, they occur in the same order relative to other page content, unless a change is initiated by the user: • Human contact details; • Human contact mechanism; • Self-help option; • A fully automated contact mechanism.

If a site or application has a help mechanism, it must be located in the same place and work in roughly the same way across all pages or screens. Why? Users with cognitive or learning impairments benefit from explanations on how to interact with content. If they can’t find this information, they might abandon the task or, in the case of sensitive contexts, need to solicit help from others in their surroundings who may not keep the information secure.

The criterion does not require the presence of a help mechanism, only that if it is provided it should be located consistently across a set of pages.

SC 3.3.7 Redundant Entry

Level A

Information previously entered by or provided to the user that is required to be entered again in the same process is either: • auto-populated, or • available for the user to select. Except when: • re-entering the information is essential, • the information is required to ensure the security of the content, or • previously entered information is no longer valid.

Everyone experiences a form of gradual mental fatigue while stepping through a process, further accelerated by having to recall information from short-term working memory. For users who have cognitive and learning challenges, this happens at an accelerated rate and with far greater regularity.

As an example, it wouldn’t be good for a customer to get all the way to your checkout page only to succumb to this stress upon having to enter their address three times–once to search for products near them, again with shipping, and yet another time for billing. This is annoying for anyone with a good working memory, but extraordinarily so for anyone without or who might be using an on-screen keyboard, smaller screen size, or assistive technology like a mouth stick.

SC 3.3.8 Accessible Authentication (Minimum)

Level AA

A cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process unless that step provides at least one of the following: Alternative: Another authentication method that does not rely on a cognitive function test. Mechanism: A mechanism is available to assist the user in completing the cognitive function test. Object Recognition: The cognitive function test is to recognize objects. Personal Content: The cognitive function test is to identify non-text content the user provided to the Website.

SC 3.3.9 Accessible Authentication (Enhanced)

Level AAA

The same as 3.3.8, except without any allowances for tests that rely on object recognition or personal content.

Getting Ready. What Should You Do, and What’s Next?

History has shown that regulatory authorities tend to provide a fair grace period (typically around a year) before fully enforcing new versions of the standards. This extended timeline offers a fantastic opportunity for companies and organizations to proactively prepare and implement WCAG 2.2 considerations into their digital offerings.

Beyond the legal requirement and proven positive impact on user experience, it is important to note that all versions of WCAG have been designed to be backward compatible. That means if you previously made sure your content was compliant and usable under WCAG 2.1 level AA, for example, it will also pass versions 2.0 and 1.0. This ensures that your efforts have a lasting and sustainable impact. No matter how much standards evolve, it is never a bad idea to start the journey toward accessibility.

Furthermore, given the relatively modest scale of changes in this release, there is a good chance that you are at least partially compliant already. Still, the more components, pages, and different pieces that make up your online portfolio, the earlier you should begin aligning with WCAG 2.2.

With today’s announcement of WCAG 2.2 as a formal recommendation, the Web Accessibility Initiative (WAI) has shifted focus onto WCAG 3.0 which is, at the time of this writing, merely a work-in-progress draft. It overhauls the current model and principles that are currently used to assess conformance but is not expected to become a complete and working W3C standard for a few more years. We will provide more information and updates as they are made available.

Let’s Discuss Your Accessibility Plans

If you don’t know where to start or find yourself in need of a hand at any point during this transition, our industry leading accessibility team would love to talk with you!