What's the Difference Between WCAG 2.0 and WCAG 2.1?

For web accessibility — making the World Wide Web equally accessible for all users, regardless of physical or cognitive ability — WCAG 2.0 by the World Wide Web Consortium (W3C) is the gold standard. Its AA level of compliance is the main reference point for accessibility standards the world over, including the United Nations, European Union, and the United States. However, WCAG 2.0 was published in 2008, and the web has changed dramatically in 10 years. WCAG 2.1 began in 2017, with its update published in June 2018. WCAG 2.1 addresses changes to the web, and how new technologies can be implemented so all users have equal access. In this blog, we’ll explain the key differences between WCAG 2.0 and WCAG 2.1, and what they mean for your site or app.

Key Differences Between WCAG 2.0 and WCAG 2.1

What is WCAG 2.0 and WCAG 2.1?

The Web Content Accessibility Guidelines (WCAG) version 2.1 builds on WCAG 2.0, but it is not meant to replace it. WCAG 2.1 gives content producers, web developers and other stakeholders the most recent web accessibility guidelines, in order to resolve questions about new technology.

According to the W3C, a larger-scale update is currently in review, most likely titled WCAG 3.0. The W3C describes this as a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance reflecting changes on the web since the publication of WCAG 2.0. The 3.0 guidelines to come will build from the most recent guidelines, so users and developers who are up-to-date with WCAG 2.1 will more easily transition to WCAG 3.0.

There are 17 differences between WCAG 2.0 and WCAG 2.1. The scope of this post is limited to significant changes likely to affect many websites, and only those concerning A or AA level compliance, which is used for most rule-making, such as Section 508 and ADA compliance.

1. Orientation: Landscape or Portrait Interchangeable

This difference mostly concerns tablets and mobile devices, which now account for the majority of web searches. When users flip a device, the orientation switches between portrait and landscape. However, some users cannot flip their device, such as devices mounted on power wheelchairs. To address this, websites should be equally accessible in either orientation. You can test this by accessing your site on a mobile device and flipping it. If it doesn’t flip, or if functionality is limited in one orientation, you’ll need to take a closer look at your CSS code.

2. Reflow: Magnification and Mobile Usability

Reflow capabilities are essential for sight-impaired users, which may include elderly users with deteriorating vision, users with conditions like cataracts, or nearsighted people without glasses. When reflow is enabled, it reorganizes the site when users zoom in. This makes text and pictures easier to see, without creating distortions or disrupting page navigation. Reflow also reorganizes pages when screen sizes change, such as between desktop and mobile devices. If you use a responsive web page design, as many accessible WordPress themes do, your site most likely already uses reflow.

3. Content on Hover or Focus: Essential for Equal Navigation

This difference mainly has to do with navigation menus. Many users navigate websites using a keyboard, which allows them to click between links. This means that if your navigation menus are only viewable when you hover over them with a mouse, and disappear otherwise, your site will not be usable to anyone not using a mouse. Allowing menus to display on hover or click can solve this problem. However, an additional click should allow the user to dismiss the menu, as a dropped menu can obscure the page when using a screen magnifier.

4. Label in Name: Accuracy for Screen Readers

Screen readers tell users how a site is organized by reading programmatic labels, also called Accessible Names. For a screen reader to tell a user what a button, list, menu, image, or search bar is and what it does, it needs an Accessible Name. This also allows a user to give spoken commands to assistive technology using Accessible Names. Often, web elements are also visually described by text, such as “Request a Quote” for a button or “Search” for a search bar. The label-in-name requirement in WCAG 2.1 requires the Accessible Name and the visual label of key elements to be the same, so those using screen readers and spoken commands can accurately interpret and interact with the site.

5. Status Messages: Telling What’s Happening

When you add an item to your shopping cart, submit a search, fill in form fields, submit a form, or run an application, a change occurs showing what you did. You don’t need to click or scroll over anything to see these messages. This WCAG 2.1 criterion addresses these messages for screen readers, allowing users to hear status changes when they occur. Similar to labels above, this can be accomplished by adding roles or properties to status messages. With the right roles and properties designated, screen readers will announce status changes.

These key differences between WCAG 2.0 and WCAG 2.1 are intended to keep accessibility guidelines evolving as technology evolves. With a few lines of code in integral places, you can ensure that all users can use your website equally. To see if your website stacks up to these changes, run a test. Automated or manual testing will reveal key issues that traditional usage with a mouse and interface can’t.