Recently the latest version of the Web Content Accessibility Guidelines (WCAG) was approved and released, adding several new guidelines for developers to follow when making sure their website is as accessible as possible. Some of these new guidelines are straightforward, while others may take a little explanation. In this post I’d like to give a brief overview of what each new recommendation is and why we should care about it.

If you’re unfamiliar, the WCAG guidelines are separated into three levels that each build on top of each other: A, AA, and AAA. Level A guidelines are considered to be the most fundamental and should be addressed first, Level AA are more advanced guidelines, and Level AAA are the strictest set of standards.  

Note: Each standard is categorized and assigned a number based on its category/subcategory. For instance, a standard for keyboard shortcuts is given the id 2.1.4. Category 2 is the “Operable” category, with subcategory 1 being “Keyboard Accessible”.

In this post I’m going to address the new standards level by level,  starting with Level A.

Level A

2.1.4 Character Key Shortcuts 

What

If your website implements keyboard shortcuts using letters, punctuation, numbers or symbol characters there are specific requirements you must meet. If you have shortcuts, you should allow the user to either turn them off, remap them, or have them only active when the component using the shortcut has focus.

Why

Users who may use a speech input device to interact with your website may find shortcuts to be frustrating or impossible to use. In addition, users who tend to accidentally hit keys may find themselves using shortcuts when they don’t intend to.

2.5.1 Pointer Gestures 

What

If you should implement any functionality that utilizes gestures (swiping, drawing, pinch zoom), then there should be a way that the user can accomplish that same functionality without the use of a gesture (unless the gesture is absolutely essential to the website).

Why

It’s important for users that may have poor fine motor control or must use an alternate input device to have a way to accomplish these operations without the use of gestures that may be difficult or impossible for them to perform.

2.5.2 Pointer Cancellation

What

When you implement actions on your website, such as a button press, its important to allow the user a way to cancel it. This can manifest in a few ways: You could choose to not let the down-event ( ‘touchstart’, ‘mousedown’, etc) execute the action. You could make the corresponding up-events reverse the action caused by the down-events. Or you could give the user a chance to abort the action before it completes (or undo it once it’s over).

Why

It’s best that it’s as easy as possible for users to recover from accidentally interacting with an element.

2.5.3 Label in Name

What

When you have an input with one or more labels ( including text or pictures of texts) the name attribute of the input should contain the same text that is visually shown.

Why

It’s important to align what we show visually with what can be found in the markup programmatically. The better aligned those are, the less confusion we cause for users who may use a speech input or a text-to-speech application.  

2.5.4 Motion Actuation

What

This is very similar to the Pointer Gestures guideline above, both of which are likely the result of increased mobile device web browsing. Any functionality that utilizes the motion of the device (such as tilting) or the motion of the user (such as making movements into the camera) should have the ability to be completely disabled. This requirement is waived if your application allows the user to activate the functionality with an accessibility device or if motion is absolutely essential to the activity.

Why

There are users who may not have the ability to move the device in the way the application requires due to lack of motor function or lack of moveable device. It’s important we allow them an avenue to the same functionality.

Level AA

1.3.4 Orientation

What

Your website should allow users to use whatever device orientation works best for them. For instance, if the user has their phone locked to the landscape orientation, your website should not continue to display in portrait mode.

Why

Some users may not be able to turn their device to a different orientation. Chair bound users may have the phone mounted to the chair in a specific orientation, and users with poor vision may prefer one orientation over the other.

1.3.5 Identify Input Purpose

What

If you’ve ever been on a website and had a form autofill for you, you’ve benefited from the thought process behind this guideline.  This guideline advises the use of the ‘autocomplete’ html attribute for inputs. By utilizing this attribute like so:

the browser will offer to autofill in all the fields it can for the user.

Why

This guideline benefits users with poor motor function, memory issues, and many other disabilities. This is a fairly straightforward thing for us to implement that can help everyone.

1.4.10 Reflow

What

To meet this standard, your website needs to be able to properly function and show content in two dimensions on a screen size equivalent to 320px wide by 256px high without requiring the user to scroll to read text. Your website needs to be able to support small screens and users who utilize browser zoom or increased text size. (Note: 320px by 256px is equivalent to 1280px by 1024px at 400% zoom). You may be more familiar with the term “Responsive Design” for this guideline.

Why

Users with poor vision may make use of the browser zoom functionality and its important that the content of your website shift to handle that change so the user is not forced to constantly scroll to see content.

1.4.11 Non-Text Contrast

What

While there has been a different level AA standard dealing with text contrast for some time, WCAG 2.1 has added a standard for non-text content. This applies to controls like buttons, links, or inputs as well as “graphical objects” such as icons or charts. The contrast in this scenario should be 3:1 and there are many online tools that can help you calculate the ratio between two colors.

Why

People with difficulty seeing may have trouble differentiating between components and their background if the contrast ratio is insufficient.

1.4.12 Text Spacing

What

This standard deals with how the text in your application is spaced and is extremely specific in what it requires. In your website the text should be able to support the following values without losing functionality or information:

• Line height at least 1.5 times the font size.
• Spacing following paragraphs at least 2 times the font size.
• Letter spacing at least 0.12 times the font size.
• Word spacing at least 0.16 times the font size.

Why

It’s important to be able to support a user setting these values based on their own needs. Users with impaired vision may benefit from a taller line height or greater spacing between words. You don’t need to have these values set that way by default, but your website does need to support them.

1.4.13 Content on Hover or Focus

What

If you choose to implement functionality where hovering over content ( or focusing content with the keyboard) reveals hidden content, this standard has specific requirements about how that hover content should work. First, if the hover content is not communicating an error or is obscuring some content the user needs to be able to dismiss the hover content without moving their pointer. Second, the user should be able to move their mouse over the content that has appeared without it disappearing. Finally, the hover content should remain visible until the pointer or focus is removed, the information in the hover content is no longer valid, or the user dismisses it manually.

Why

Users with disabilities may unintentionally trigger hover content and abiding by this standard allows them to easily dismiss the content if this is the case. On the flip side, users with low vision will appreciate the measures taken so that they can take their time to read this hover content without it disappearing.

4.1.3 Status Messages

What

During the course of the user’s time on your website they will undoubtedly encounter various status messages. WCAG specifically defines status messages as a message that “provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.” A validation error, a loading message, or a success banner could all count as a status message. To meet this standard, we need to add the proper marking to the messages, with slight variations depending on the situation:

Why

Users with poor vision may require the use of screen readers to experience the content on your website. By adding this markup, we properly alert the screen reader to important updates appearing that they may otherwise miss.

Level AAA

1.3.6 Identify Purpose

What

This standard will require you to properly identify a variety of things within your website. To begin, it’s important that you identify the various regions of your page using the ARIA landmarks. This would include identifying areas like the banner, the “main” area of the application, or the navigation bar. Then, you should work to identify the specific purpose of icons, inputs, and other similar components in markup on the page.

Why

Users with memory or focus issues can utilize various tools that allow them to highlight or remove areas of the page based on the markup, simplifying the application. In addition, by properly identifying icons and inputs, the user can use accessibility tools to swap in graphics more familiar to them. This helps to eliminate confusion for these users, and allow them to be instantly more familiar with an otherwise unfamiliar website.

2.3.3 Animation from Interactions

What

If you’ve implemented animation in your website, such as parallax scrolling or animation when transitioning to new content, there needs to be a way for the user to disable said animation.

Why

Animations like the ones I listed have a tendency to cause dizziness and headaches for users with inner ear disorders. Without being able to turn off animation, those users may be unable to utilize your application.

2.5.5 Target Size

What

When you’ve got a clickable element on your page, this standard specifies that the clickable target size for this element must be at least 44px by 44px. However, there are specific exceptions to this rule. If the element is inline in some text, the target area can match the size of the text around it. In addition, if the size of the target modified by the user agent and not your CSS then it also meets this standard. Finally, if it’s absolutely essential that the target size is less than the standard specification, then it also passes.

Why

There are a lot of use cases where having a larger target size can be beneficial. Users on touch screens, users with poor fine motor skills, and even users who can’t see very well are just a few examples of people who will benefit from implementing this standard.

2.5.6 Concurrent Input Mechanisms

What

This standard states that your website should not limit the user to a particular input mechanism. For instance, while the user may primarily use a mouse to navigate your website, they should also be able to use the keyboard, a speech input, or a touch screen if that is their preferred input method.

Why

There are so many different inputs a user could employ to interact with your website, and if we limit their input choice then we make it difficult for some to use it. Users should be able to make their own choice about how they interact with your application, and switch between input methods as they see fit.

With that we’ve reached the end of all the new guidelines! I hope you found this summary of WCAG 2.1 to be helpful and informative for making your own website more accessible to more people. As our technology continues to progress this will certainly not be the last update we get to the WCAG. So keep your eyes open, because one day down the line you’ll probably be hearing from me again!