Accessibility: What's New in WCAG 2.1?

Nearly a decade after its initial release, the Web Content Accessibility Guidelines (WCAG) 2.0 has officially been updated to 2.1. This release focuses primarily on mobile accessibility, users with low vision, and users with cognitive and learning disabilities. With 17 new success criteria in place, let’s see what’s different!

The Quick and Dirty

• WCAG 2.1 is an extension of WCAG 2.0.
  • Everything that was in 2.0 is still in 2.1, with the same numbering system.
  • WCAG 2.1 is backwards-compatible. If your content conforms to 2.1, it also conforms to 2.0.
• WCAG 2.1 is an official W3C Recommendation
  • At the time of this writing, most laws—like Section 508 and various international laws—only require your site to be 2.0 compliant.
  • But, if you’re developing or updating content or accessibility policies, the W3C encourages you to use the latest version of WCAG.
• In order to fulfill the Full Page Conformance Requirement, all variations of the page across all breakpoints must be in conformance.
  • Make sure your mobile and tablet views are just as accessible as your desktop views, folks!

New WCAG 2.1 Success Criteria

1.3.4 Orientation (Level AA)

Some users can’t change, or can’t easily change, the orientation of their web devices. So, we should ensure that our sites can be used in both portrait and landscape orientations.

Along with those who have their devices mounted in a fixed orientation, this success criterion also helps folks with low-vision, since changing the content’s orientation often increases text size.

The one exception is when “a specific display orientation is essential.” In this case, “essential” could be a banking app that forces you to take a picture in landscape mode to accurately photograph the check you wish to deposit.

Great news: if you already have a responsive framework on your site, you’ll likely pass this success criterion!

1.3.5 Identify Input Purpose (Level AA)

We should help browsers automatically fill out our forms. When we use the HTML autocomplete attribute, we’re helping those with dexterity disabilities who have trouble typing, users with language-, memory-, and executive function-related disabilities who may take more time to process information and the directions asked of them, and literally anyone who hates filling out forms.

1.3.6 Identify Purpose (Level AAA)

Our HTML could should provide “context, propose, and meaning of symbols, regions, buttons, links, and fields.” For example, users who have a cognitive disability might find it difficult to concentrate if there are many sections of a page present. If our site uses ARIA landmarks to identify the regions of our pages, this user could use their assistive technology to hide all of the regions that weren’t marked “main.”

This also goes hand-in-hand with the W3C’s Personalization Semantics, which is an exciting initiative in itself.

For a demo of what this would look like, check out the W3C’s sample website.

1.4.10 Reflow (Level AA)

Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:

• Vertical scrolling content at a width equivalent to 320 CSS pixels;
• Horizontal scrolling content at a height equivalent to 256 CSS pixels.

In layman's terms, your website and its elements must be responsive. The exception would be for anything that would lose its meaning if it were to collapse into one column (e.g. a map). This success criterion is a huge win for user experience, and those with visual disabilities who need to zoom-in to read content.

1.4.11 Non-text Contrast (Level AA)

Elements like buttons, icons, and infographics now have to meet a color contrast minimum. This includes these elements’ focus states, as well.

1.4.12 Text Spacing (Level AA)

Users must be able to increase line height, spacing following paragraphs, letter spacing, and word spacing without losing content or functionality. 

The WCAG says that all content and functionality must remain available and visible if the user were to change:

• line height to at least 1½ × the font size;
• space below paragraphs to at least 2 × the font size;
• letter spacing to at least 0.12 × the font size; or
• word spacing to at least 0.16 × the font size.

This success criterion lets users with low-vision or dyslexia customize their reading experience to better fit their needs.

Steve Faulkner has a Text Spacing Bookmarklet on codepen to do a “quick and dirty” test for this!

1.4.13 Content on Hover or Focus (Level AA)

In recent years, a common trend on certain websites is to display a popup, typically asking you to sign up for a newsletter, when you hover or tab onto a certain part of the screen. If there are areas on your site that when new content appears if a user hovers or tabs on an element, ensure that:

• This content can be dismissed without moving their pointer or tab onto some other element.
• This content will not disappear if the user moves their mouse over it
• This content remains visible until the hover or focus trigger is removed, the user dismisses it, or the content is no longer valid.

This lets users who increase the size of their mouse cursor or users who have low pointer accuracy see content unobscured and easily dismiss unintentionally-triggered additional content. This also grants users who have cognitive disabilities adequate time to perceive additional content that appears on screen.

2.1.4 Character Key Shortcuts (Level A)

If your website supports keyboard shortcuts that uses only one key (including upper- and lower-case letters, punctuation, number, or symbol characters), then at least one of the following must be true:

• The shortcut can be turned off.
• The shortcut can be remapped to use one or more non-printable keyboard characters (e.g., Ctrl, Alt).
• The shortcut is only active when the component has focus.

Users who have a permanent or temporary dexterity limitations may be prone to accidentally hitting keys. Having the ability to turn off these shortcuts or modify them to include another key would cut down on accidentally triggering shortcuts. Speech users would also want these single-key shortcuts turned off so they can avoid accidentally firing batch of them at one.

2.2.6 Timeouts (AAA)

If there is a timeout on any part of your site, you have to either store the user’s data for at least 20 hours, or, at the beginning of the process, warn the user that your site will timeout after a specific amount of time.

Note: Under this success criterion, the WCAG makes a callout that I will also echo here:

Privacy regulations may require explicit user consent before user identification has been authenticated and before user data is preserved. In cases where the user is a minor, explicit consent may not be solicited in most jurisdictions, countries or regions. Consultation with privacy professionals and legal counsel is advised when considering data preservation as an approach to satisfy this success criterion.

Users with language-, memory-, and focus-and-attention-related disabilities, as well as disabilities that affect executive function and decision, may not just need more time to complete certain tasks, but may require taking breaks. 

2.3.3 Animation from Interactions (Level AAA)

Motion animation triggered by interaction can be disabled, unless the animation is essential to the functionality or the information being conveyed.

Imagine you have a web app that lets you create an animated scene. You would then need to preview the animation that you created. In this case, the part of this app that lets you preview the animation would be considered “essential.”

Motion animations, like the parallax effect or elements that change as the user scrolls, can trigger vestibular (inner ear) disorders. The impact of these animations on users with vestibular disorders can range from dizziness, nausea, and trouble walking to distraction, migraines, and needing bed rest.

Though there is limited browser support (at least at the time of this writing), you could start using prefers-reduced-motion media query. This media query lets you target users who have selected the “Reduce Motion” setting on their device’s operating system. 

Note: “Animation from interactions” applies when a user’s interaction initiates non-essential animation. In contrast, 2.2.2 Pause, Stop, Hide applies when the web page initiates animation.

2.5.1 Pointer Gestures (Level A)

If your site uses multi-touch gestures to perform certain tasks, you need to make sure that the same task can be performed with a simpler, single gesture.

A common example of this in action would be the iPhone’s zoom. Looking at a picture, I can zoom in by spreading two fingers apart or by double-tapping the image. For folks with limited motor skills, having a simple way to perform complex gestures is essential.

2.5.2 Pointer Cancellation (Level A)

Have you ever written an email or filled out a form, and as you pressed down on the “Send” button, you realized you didn’t want to send it, so you try to move your cursor or finger away from the button before lifting up, but the message still sent anyways? Well, this success criterion would prevent anxiety-inducing experiences like that. Now, down-events (clicking, tapping, or long-pressing on) cannot be used to complete a function and that users can prevent an action by moving their finger or pointer away.

2.5.3 Label in Name (Level A)

This success criterion is a huge win for speech input and text-to-speech users. Text that appears on a form control or image must match how the HTML identifies that form control or image. We do this through proper semantic HTML—using the label element, alt and aria-labelledby attributes. Also, our visible labels must match its accessible name or programmatic label.

When we do this, these users can activate controls much easier. When we don’t do this, we create a frustrating experience for users when they say a visible text label but the speech input does not work because the accessible name does not match.

2.5.4 Motion Actuation (Level A)

Your site may let visitors use certain motions to perform a task, like shaking their device to undo text that they just typed. If your site makes use of motion gestures, you must provide a way to make that same functionality available to users who can’t, won’t, or don’t want to perform motion gestures. You also must make sure that there’s a way for users to turn off these motion controls, so they do not accidentally trigger a response.

2.5.5 Target Size (Level AAA)

Have you ever tried to tap on a form button or the close icon of a modal, just to have your finger be too big for the screen to register it as a tap? Fear no more! The Target Size criterion says that all interactive elements should have at least a 44px width and height.

2.5.6 Concurrent Input Mechanisms (Level AAA)

Our devices allow us to interact with them in a plethora of ways, especially when we use different accessories (like a stylus) or connect input devices (like a keyboard) to them. Websites should allow users to switch between these modalities. For example, if I’m filling out an application on your site through voice input, I should be able to turn off that feature and use a keyboard and mouse instead.

4.1.3 Status Messages (Level AA)

There’s lots of reasons we alert users on the status of what they’re doing. Sometimes it’s because there’s an error on the form they just filled out, or that they successfully added an item to their cart. Sometimes it’s to let them know where they are in a process, like on a multistep form. When we alert users of these things, we need to make sure that their assistive technologies are alerted as well, and that we’re not interrupting the user by focusing them on another element or putting them on a new page.

By using the appropriate ARIA roles for these messages, we can ensure all of those things.

• Use role=“status” for results of an actions, like a successful form submission.
• Use role=“alert” or aria-live=“assertive” to identify errors, like an incorrect value on a form.
• Use role=“progressbar” to let users know where they are in a process.  

Wrapping Up

Hopefully this guide has made the WCAG 2.1 a bit more accessible for you, dear reader. And while these additions lay out how to make the Internet a more inclusive and flexible place, it’s your commitment to web accessibility that puts it into action. As Smokey the Bear once definitely said, “Only you can prevent inaccessible websites.”