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, among others. However, WCAG 2.0 was published in 2008, and the web has changed dramatically in 10 years. WCAG 2.1 began in 2017, with the latest update (as of this writing) 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, also known as 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 W3, a larger-scale update is currently in review, most likely titled WCAG 3.0. W3.org explains, “This is a multi-year effort, so WCAG 2.1 is needed as an interim measure to provide updated web accessibility guidance to reflect changes on the web since the publication of WCAG 2.0.” The 3.0 guidelines yet to come will build from the most recent current guidelines, so users and developers who are up-to-date with WCAG 2.1 will more easily transition to WCAG 3.0, which may replace WCAG 2.0 eventually.
There are 17 differences between WCAG 2.0 and WCAG 2.1. The scope of this blog 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. For a full list and further explanation of changes, see WCAG 2.1 section 0.5.1
1. Orientation: Landscape or Portrait Interchangeable
This difference between WCAG 2.0 and 2.1 mostly concerns tablets and mobile devices, which now accounts for the majority of web searches. When users flip a device, such as a tablet or smartphone, 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 simply accessing your site on a mobile device and flipping the device. 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 certain conditions like cataracts, or nearsighted people without glasses or contacts. 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. This makes reflow ideal for mobile page design as well. If you use a responsive web page design, as many accessible WordPress themes are, your site most likely already uses reflow. You can also create an alternate mobile version of your site with a fixed 320 pixel wide layout.
3. Content on Hover or Focus: Essential for Equal Navigation
This difference between WCAG 2.0 and WCAG 2.1 mainly has to do with navigation menus. Remember that many users navigate websites using a keyboard, which allows them to click between links. This means, 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. Many accessible web page themes will already have this capability, and others can be changed with CSS code.
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 be able to tell a user what a button, list, new menu, image, or search bar is and what it does, it needs a 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. Adding label properties to key elements will account for this difference between WCAG 2.0 and WCAG 2.1.
5. Status Messages: Telling What’s Happening
When you add an item to your shopping cart, submit a search on a website, fill in form fields, submit a form, or run an application, among other things, a change occurs showing what you did. You will see that your shopping cart now has another item, that your form fields were or weren’t correctly filled in, that your form was or wasn’t successfully submitted, or that the application you clicked is running. 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 and is accessible to all users, run a test. Automated or manual testing will reveal key issues in your site’s accessibility that traditional usage with a mouse and interface can’t.