A person wearing a suit jacket holds a tablet, from which a stream of hexagonal shapes are flowing out. Some of the hexagons have words, ex. 'WCAG' and '2.2', and 2.1

WCAG 2.1 vs. WCAG 2.2: A Brief Overview

Do you know about the changes coming with the new release of WCAG 2.2?

The Web Content Accessibility Guidelines (WCAG) is an internationally recognized standard whose primary aim is making web content accessible for people with disabilities. The World Wide Web Consortium (W3C), founded by Sir Tim-Berners Lee in 1984, has played a crucial central role in the development, progress, and promotion of WCAG.

The consortium unites companies committed to creating standards and recommendations for improving the quality of the Web. Their work is an ongoing undertaking with no projected end. Why? As technology advances and accessibility needs evolve, so do the guidelines. As such, we’ve seen a growth in success criteria, and other iterative enhancements.

In February 2020, W3C published the first working draft of WCAG 2.2, an extension of WCAG 2.1. While there aren’t a huge number of changes between the two versions, WCAG 2.2 introduces nine additional success criteria, including one that was promoted from AA to A. These revisions primarily focus on compliance and web accessibility for touchscreens and mobile platforms, as well as eBooks and other digital content types.

The key differences between WCAG 2.1 and 2.2 appear to lie in the success criteria. WCAG 2.2 is a more comprehensive guideline for website owners, developers, content creators, and students, aiming to make web content accessible to everyone. The update to WCAG 2.2 essentially addresses the ever-growing number of mobile users, helping create websites with better accessibility for mobile devices, a necessity based on how users are utilizing more and more mobile tech to engage with content.

WCAG 2.2 builds upon previous iterations (2.0 and 2.1) and ensures conformity with the earlier versions. The new version introduces additional criteria while maintaining a ‘backward compatibility’. Notable changes include the promotion of 2.4.7 Focus Visible from Level AA to Level A and the removal of 4.1.1 Parsing.

The nine additional success criteria in WCAG 2.2 have a deeper focus on various aspects of web accessibility, including visible focus states, draggable movements, target size, consistent help, visible controls, accessible authentication, and redundant entry. A detailed examination of these changes can be found on the W3C.org website.

Although the WCAG guidelines are primarily designed to improve accessibility for people with disabilities, they in fact benefit everyone by enhancing SEO and overall usability. For example, closed captioning, initially created for the deaf or hard of hearing, is useful for anyone watching videos in quiet environments (in libraries or quiet workspaces, or at home with sleeping babies, for example).

As technology advances and users’ needs evolve, WCAG will continue to be updated, as has already been seen via the various iterations this far. As such, organizations must remain vigilant in testing their websites and apps to ensure continued compliance and accessibility. Consulting with digital accessibility experts can help businesses stay proactive in maintaining an accessible online presence.

The 9 additional success criteria are as follows:

1) Guideline 2.4.7 Focus Visible (A)

Not a new success criterion, but as mentioned, it has recently been promoted from AA to A.

That said, WCAG 2.2 now allows one to use the default browser focus state or create your prominent focus states.

There are three ways to maintain your focus state branding. You can achieve this by:

  • reversing the link and background colours
  • adding a thick border
  • using a combo of the aforementioned two strategies

2) Guideline 2.4.11 Focus Visible (Enhanced AA compliant)

According to this particular WCAG 2.2 guideline, your design system focus states should display visible keyboard focus indicators by:

  • Surrounding the entire focused element with a 1-pixel or more significant border
  • Having an 8-pixel or greater edge on the shortest side
  • Maintaining a colour change with a 3:1 contrast ratio from the unfocused state
  • Maintaining a 3:1 contrast ratio with background colours or having 2 pixels or greater borders surrounding the focused element.

Also, it is important to make sure any focusable elements taken out of the design system and used on the website or app do not overlap or hide the focus indicator with other screen elements.

3) Guideline 2.5.7 Dragging Movements (AA)

According to this guideline, WCAG 2.2 specifies that developers must provide alternatives to the dragging action in user interface components.

The only exception: when dragging is vital, for example, when a user adjusts the price range search filters.

This is a crucial enhancement that can prove helpful when a user may need to drag and reorder apps on a homepage in an organized manner.

Note: This particular guideline helps by ensuring that people with disabilities no longer feel left out because they cannot do things like dragging with a mouse.

4) Guideline 2.5.8 Target Size (Minimum) (AA)

This new guideline mandates that web owners keep sufficient space around fixed reference points like navigation links and form fields that aren’t inline. The only exception is in the case of links placed within bodies of text, like paragraphs.

In addition, tiny targets measuring less than 44 pixels in width or height should have at least 44 pixels high and side selection area. It is also acceptable to offer users a way to enlarge elements to at least 44 pixels in width and height.

Note: one benefit is that it affords everyone visiting the website the convenience of clicking on any user interface component. It isn’t only those born with a mobility impairment that benefits. Injury and aging can lead to the loss of motor control, making it hard for users to click on elements found on mobile devices. It can be equally beneficial to those with large fingers or those with poor hand/eye coordination.

5) Guideline 3.2.6 Consistent Help (A)

This success criterion specifies that contact details, like phone numbers, chatbots, emails, and the like, should be found in the same place on all web pages. This applies both visually and in code.

Note: This new guideline is crucial because there remains the chance that the user may wish to opt to contact the website owner or business directly. The more quickly the user can find the contact info for the business, for instance, the quicker they can do business, reach customer service, book an appointment or make an inquiry. Even when a user does not need immediate assistance, just knowing that there is help available can boost their confidence.

6) Guideline 3.2.7 Visible Controls (Level AA)

This new success criterion in WCAG 2.2 requires that a website not hide critical controls to a process behind a hover or focus state. For example, an e-commerce app or website must not have checkout buttons that appear only if the user hovers over its text.

The best way to ascertain whether critical controls are accessible or not is through usability testing. This testing helps you detect actions that will burden a user or make a user’s experience a bad one. For this kind of testing, it is strongly recommended to have people with various technical capabilities, like experts and novices, do the testing.

7) Guideline 3.3.7 Accessible Authentication (A)

To provide true web accessibility, you must make your visitors’ experience as pleasant, easy, convenient, and comfortable as possible. A rough user experience is not an accessible one.

Obliging users to recall and type in passwords manually for user authentication, they should instead be permitted to copy and paste passwords into form fields.

They should alternatively be allowed to:

  • Use password managers.
  • Use their device face scan to authenticate.
  • Use OAuth to authenticate third-party providers.
  • Use a USB two-factor authentication method where users can press buttons instead of typing unique codes.
Note: It is far better to offer a multitude of ways to authenticate so that users can find one way that works best for them. This helps users with cognitive disabilities, especially because it speeds up online interactions and reduces stress, creating a much better user experience from the start. In addition, the more easily visitors can perform their login, the more simple it is to secure accounts from third parties.

8) Guideline 3.3.7 Accessible Authentication (AAA)

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.

9) Guideline 3.3.9 Redundant Entry (A)

With this success criterion, web owners must reduce a user’s time to re-enter identical information while filling out forms. As an example: Users should not have to enter the shipping and billing address twice if they are the same.

Auto-populating fields with any data the user has stored in the browser wherever possible is an infinitely better scenario. The only exception would be the re-entering of crucial security verification data, like while validating passwords for instance.

Note: Benefits include an improved web experience. Users with disabilities that depend on assistive tech like screen readers, for instance, may find it difficult and arduous to use sluggish on-screen keyboards, less-than-perfect voice dictation, and websites that automatically log out slow-moving users.

By allowing for users to enter information once only, users can experience a much more nimble and far less aggravating user experience. Likewise, it gives users sufficient time to ensure they enter information that is accurate and complete.

A deeper look at more changes in detail is available on the W3C.org website at https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/ where links are included to help understand the success criteria listed in detail, with some comprehensive examples.

Universal benefit

It is most important to keep in mind that the WCAG guidelines benefit everyone.

While it remains true that the guidelines themselves and the iterative expansion and enhancements to the guidelines are meant to improve the navigability, and the readability of online content for people with disabilities, there are many unexpected and peripheral benefits for everyone, including improved SEO, and better usability for all. 

Closed captioning for instance is designed to help those who are deaf or hard of hearing. But some people may have to, from time to time, press mute on a video to avoid disturbing others, avoid waking a sleeping baby, or be able to watch what would otherwise be a loud or disruptive video somewhere quiet, like in a workplace or library, and will benefit immensely from closed captioning as an example.

What doesn’t change in moving from WCAG 2.1 to WCAG 2.2?

While many are pointing out that there are some significant differences between WCAG 2.1 and 2.2, and that these differences seem, at first glance, somewhat overwhelming, there are 3 major aspects to ensuring compliance that remain unchanged:

1)    Website owners and developers must continue to test their websites and their apps to ensure continued web compliance for users of assistive technology. Accessibility and compliance aren’t a “one-and-done” thing.  As content is added and as new elements are added, (or augmented, moved, or taken away) it can have a ‘domino effect’, or negative repercussions on the accessibility and compliance of your website or apps. Continuous or regular testing and monitoring are a necessity and the only way to have assurance and certainty.

2)    WCAG isn’t ‘final’, and as technology advances, and with it the way people with disabilities engage with online content, so too will WCAG.  The W3C will continue to monitor, assess, and make recommendations, and continue to update WCAG as a result.

3)    Organizations will still need to consult with experts in digital accessibility to ensure that their website(s) and apps remain compliant and accessible. Our team of accessibility experts is ready to help you assess your current state and will not just advise on removing the barriers to accessibility that exist within your website and digital products but will help you become more proactive in guiding you on how to circumvent the risks and reap the rewards of not making the same errors again in the future.

Share this post on:


Related Content