The Web Content Accessibility Guidelines (WCAG) are the de facto industry standard for website accessibility. The WCAG details the criteria you need to meet to make your site accessible to all users. Well-known recommendations include adding alt text to images and closed captions or transcripts for videos.

The WCAG 2.1 was the latest iteration of the standards, introduced in June 2018.

Editor's Note: WCAG 2.2 is here! Click to read more about what the release of WCAG 2.2 means for your business.

Even with the release of WCAG 2.2, WCAG 2.1 is the most adopted industry standard for accessibility. WCAG 2.1 has 17 additional usability and accessibility considerations. WCAG 2.1 offers two important benefits for users of assistive technology over 2.0.

• Enormous focus on mobile, which was a big gap in WCAG 2.0 even though it’s a fundamental channel with significant developments from both iOS and Android
• Specifically addresses issues for users with motor and dexterity disabilities, individuals with low vision, those with vestibular disabilities, and people with cognitive disabilities. 

Following the WCAG 2.1 guidelines is the best way to ensure that digital content and environments (including your website and apps) are usable and accessible for people with disabilities. In addition, based on recent legal trends, adhering to WCAG 2.1 is the safest bet to protect your business from accessibility lawsuits and liabilities.

Test your site against WCAG 2.2 standards here.

In discussing WCAG 2.1, we’ll touch on why the W3C decided to update the standard, what’s different compared to WCAG 2.0, why you should be following these recommendations, and how you can get started making these changes.

Why the Change?

There are many reasons that the W3C decided to create the WCAG 2.1 in lieu of a brand new standard (such as the upcoming WCAG 3.0 AG Working Group). According to the W3C, WCAG 2.1 was initiated with the goal to improve accessibility guidance for three major groups: users with cognitive or learning disabilities, users with low vision, and users with disabilities on mobile devices. Although a WCAG 3.0 is very much in the works, they felt a need to address these critical user groups in an agile way.

Ultimately, the W3C created WCAG 2.1 to help people; users with disabilities that needed clarity on the existing standards to ensure a seamless experience on websites, apps, and other applicable digital content.

The Differences Between the WCAG 2.0 and 2.1

There are seventeen new criteria that differentiate the WCAG 2.0 and the WCAG 2.1. But the biggest difference is the advanced considerations for mobile users.

WCAG 2.1 has a larger occurrence on mobile usage and the preferences of those with low vision and those with cognitive disabilities. Mobile was overlooked in past accessibility guidelines like WCAG 2.0.

In today’s world, many of us, including people within the disability community increasingly rely heavily on mobile for everyday tasks. This makes moving to the standards outlined in WCAG 2.1 all the more urgent.

All of the mandates from 2.0 are included in 2.1, so if you were previously up to date, you can build on the changes you already made and simply incorporate the new requirements.

These are the new criteria that you’ll need to include:

• Orientation. The site or app must work regardless of the orientation of the device. If a wheelchair user has a tablet attached to their device and can’t rotate it horizontally, they should still be able to use the site.
• Identify Input Purpose. Auto-fill or auto-correct suggestion text for input fields, including for things like customer addresses.
• Identify Purpose. The purpose of UI components, icons, and regions should be programmatically determined in content using markup languages.
• Reflow. Content can be presented without requiring scrolling in two dimensions. (See specific dimensions here).
• Non-Text Contrast. Presentation of UI components and graphical objects must have a contrast ratio of at least 3:1 against adjacent colors.
• Text Spacing. No loss of content or functionality happens by setting text spacing and changing no other property in content implemented using markup languages.
• Content on hover or focus. When receiving and removing pointer hover or keyboard focus to reveal additional content, you need the additional content to be dismissible, persistent if the user is still hovering, and still available once the pointer moves over the additional content.
• 4 Character Key Shortcuts. Mechanisms must be available to turn shortcuts on or off, to remap a shortcut, or to only become active when the component has focus.
• Timeouts. Users are warned about the duration of inactivity that could cause data loss unless data is preserved for more than 20 hours.
• Animation from Interactions. Motion animation triggered by interaction can be disabled unless it’s essential to the functionality or information being conveyed.
• Pointer Gestures. All functionality using multipoint or path-based gestures can be operated with a single pointer without path-based gestures unless they’re essential.
• Pointer Cancellation. For functionalities that can use a single pointer, there must be either a no-down event, an up reversal, an abort or undo option for down-events unless they’re essential.
• Label in Name. UI components with text or images-of-text labels, the text must be presented visually.
• Motion Actuation. Functionality operated by device or user motion can also be operated by UI components, and the motion can be disabled except in a few particular use cases.
• Target Size. The size of the target for pointer inputs is at least 44x44 CSS pixels, barring a few particular exceptions.
• Concurrent Input Mechanisms. Web content can’t restrict the use of input modalities available except where restriction is essential to ensure security or respect user settings.
• Status Messages. Status messages can be determined through properties so they can be presented with assistive technologies without receiving focus on content implemented using markup languages.

Why Adopt WCAG 2.1 Recommendations

Some key info informing our recommendation to all clients and partners to make the switch to WCAG 2.1:

The WCAG is often referenced in ADA complaints, and more than 75% of all federal claims currently reference WCAG 2.1 (level AA)

• The California Consumer Privacy Act drafted regulations based on the WCAG 2.1, and it’s the standard there for all sites and vendors
• Section 508, US DOT ACAA, and AODA from Ontario, Canada are all still requiring the WCAG 2.0AA for now
• Certain vendors do require the WCAG 2.1 in their MSA. Companies like Verizon, for example, include accessibility and AD providers in their standard terms for vendors, requiring vendors to provide full documentation of measures taken to ensure that the regulations have been met

In addition to allowing for greater accessibility and usability so that all users have a positive experience with your brand, fully integrating these standards into your website and mobile apps will better protect you from legal and compliance issues. 

Prepare Your Accessibility Program for 2025

Adopting WCAG standards like 2.1 and 2.2 is vital, but building a successful accessibility program requires a comprehensive strategy. If you're ready to take your accessibility efforts to the next level, join our upcoming webinar, “5 To-Dos for Your 2025 Web Accessibility Program.”

In this session, we’ll cover actionable steps to ensure your digital properties are compliant and provide an inclusive experience for all users.

Sign up today to secure your spot!