What’s New in WCAG 2.1?
Perhaps you’ve heard that the W3C (World Wide Web Consortium) has updated their Web Content Accessibility Guidelines (WCAG) 2.0.
- On April 24th, 2018, W3C posted a proposed extension of Web Content Accessibility Guidelines (WCAG) 2.0, referred to as WCAG 2.1.
- On June 5th, 2018, WCAG 2.1 was no longer considered a proposal. WCAG 2.1 includes 2.0 and 17 new criterion.
When will I need to update my website?
Is there a law someplace that answers this? An official interpretation? A lawsuit that references the new criterion?
To date, in the United States, there is an understanding that WCAG 2.0, levels A and AA, is the required version and levels of accessibility required to create an ADA compliant website. Court case summaries posted by the legal community say this is so.
But, as of August 2018, this reviewer can’t find a court case that references WCAG 2.1.
Should you sigh in relief? No. Right now, the courts are interpreting Titles II and III and hearing complaints. Will a judge bring his or her hammer down on one of the new criteria if you aren’t compliant with it? Quite possible. One would hope for a reasonable ruling: no penalties and perhaps a date allowing you time to fix the issue given the newness of the additional criterion.
As soon as this happens, you have your precedence. You have your clock. Of course, until Section 508 is updated, federal site owners are protected, but that doesn’t mean said site owners should ignore the new criterion as they update or rebuild their sites.
What kind of changes will we see?
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.”
The fact that these new criteria were added with mobile devices and users in mind should not come as a surprise. In 2015, the W3C released Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile. They’ve been working accessibility for mobile devices for some time.
Are we talking about a lot of change?
Depends on what you are doing on your site. It’s possible you have nothing to do or change in order to meet one or more of the 17 additional criterion. Perhaps you are hoping that most of the 17 criterion are level AAA and you won’t be held accountable. Let’s clear this one up right now. Twelve of the 17 are A or AA.
At this point, we could simply list the new criterion by the principles of POUR (Perceivable, Operable, Understandable, Robust) or by level, leaving you to mentally map the criterion to how you think about your site and its functionality.
Instead, the following is offered in hopes to provide a unique and helpful perspective on the new criterion.
Each criterion will be briefly explained. You will benefit from reviewing the criterion’s Understanding pages as that is where you will find a more precise set of instructions.
Interactions and Orientation
Your site is “touched” and “viewed” using multiple methods.
The oldest method being via mouse or touchpad and the pointer they control on a computer monitor. Next up is the keyboard and monitor. WCAG 2.0 included criterion 2.1.1 Keyboard, for example, to address keyboard tabbing on websites.
Given the fact that mobile devices and touchscreens are pervasive in the world today, it’s no surprise that several of the new criteria are focused on “touching” and “viewing” said technology.
- 1.3.4 Orientation (A)
- 1.3.5 Identify Input Purpose (AA)
- 2.2.6 Timeouts (AAA)
- 2.1.4 Character Key Shortcuts (A)
- 2.5.1 Pointer Gestures (A)
- 2.5.2 Pointer Cancellation (A)
- 2.5.4 Motion Actuation (A)
- 2.5.5 Target Size
- 2.5.6 Concurrent Input Mechanisms (AAA)
Success Criterion 1.3.4 Orientation (AA)
Bottom line, don’t prevent someone from viewing your content in the display orientation of their choosing. Of course, there are exceptions, but if you don’t have to lock your content in portrait or landscape display, then don’t. This isn’t a feature you would accidentally enable, especially if your site is responsive.
Success Criterion 1.3.5 Identify Input Purpose (AA)
You know when you fill out a form online that includes your name and maybe your address and all you have to do is start typing and you are given the option to autocomplete the form? Autocomplete is a feature in HTML5.2. This works because there is a defined purpose to the field.
Criterion 1.3.5 is about ensuring the purpose of the field is clear. They reference autocomplete technology as a means of satisfying this criterion. However, the intent is “to help people recognize and understand the purpose of form input fields. … form input fields require programmatically determinable information about their purpose.”
If you have some forms on your website, you might want to look into whether you are already using HTML5.2 and providing input purposes.
Success Criterion 2.2.6 Timeouts (AAA)
Not everyone can interact with your site forms quickly. It can take time to fill in a field thus creating lengthy interactions.
So, are you collecting job applications online via form? Are your visitors entering data for anything that might take more than a minute or two? This one's for you.
It’s likely that you are already advising your visitors that there is a time limit for interacting with your site if indeed there is one. If not and there is a chance that their efforts will be in vain if the session times out, you need to warn them. If you are storing their data as they go along and thus there are no concerns if they walk away and return the next day, providing a timeout notice is not required.
Success Criterion 2.1.4 Character Key Shortcuts (A)
Are you adding keyboard functions to your pages? No? Then you are good to go. If yes, then you have a new criterion to review. You don’t want to override an existing keyboard shortcut implemented by assistive technology. This criterion gives you guidance in the changes you might need to make.
Success Criterion 2.5.1 Pointer Gestures (A)
What are pointer gestures? Have you ever used two fingers to zoom in or out on your mobile device screen? If you are providing an interface, such as a map, where the user would want to zoom in or out, you might need to add a single input option. According to W3C, including [+] or [-] buttons will accommodate this criterion. For other examples, visit 2.5.1’s Understanding page.
Success Criterion 2.5.2 Pointer Cancellation (A)
If you have, you need to edit your code to not include a down event such as touchstart or mousedown. W3C includes other alternatives to tweaking your code.
Success Criterion 2.5.4 Motion Actuation (A)
Do you have an app? Is your site presented via an app? If yes, this one might apply to you. This criterion is focused on interfaces that respond to device movements. Not a common feature on websites presented via a browser but definitely a possibility in apps you might be using to present your content.
If you have added functionality to your app that, for example, advances a user to the next page when they tilt their device, then you need to pay attention to this one. Users need the option to advance to the next page via the user interface and not when their hand accidentally moves, mimicking a tilt.
To prevent your application from behaving as such in a mobile device, you need to add a setting that disables the response to movement.
Success Criterion 2.5.5 Target Size
On a full-screen display, it’s easy to imagine large buttons, for example, being acceptable from a design perspective. Shrink that web page down into a small mobile device and that button can become a tiny dot that someone has to hit with a finger or other handheld pointer.
If you have buttons or links or other features that require interaction, they need to be big enough to be touchable - even on the small mobile screens. The Understanding page for 2.5.5 presents a couple of scenarios that you should review if you have such interactive links on your pages.
Success Criterion 2.5.6 Concurrent Input Mechanisms (AAA)
To say this is a level AAA criterion seems odd to this reviewer. Why would you prevent someone from using an external keyboard to enter data or interact with your site versus the in-device touchscreen? If you aren’t doing this on purpose and your site doesn’t care what a user uses (mouse, keyboard, touch), then you can check off a level AAA criterion.
If you have an essential reason for such a restriction, then, okay. Although the criterion doesn’t say you have to explain yourself, the instructions for such interactions might be a place to make this clear.
It’s not just words that convey meaning. It’s the style and shape of the content. You might recall two criterion introduced in WCAG 2.0 that focused on ensuring that a user of a website would not miss out on what the content is saying or implying.
- Criterion 1.3.1’s intent is “to ensure that information and relationships that are implied by visual or auditory formatting are preserved when the presentation format changes.”
- Criterion 1.3.2’s intent is “to enable a user agent to provide an alternative presentation of content while preserving the reading order needed to understand the meaning.”
Two new criterion has been added on this note.
- 1.4.10 Reflow
- 1.4.13 Content on Hover or Focus
Success Criterion 1.4.10 Reflow
If your site or app is already responsive, you are well on your way with this one. As long as your content fits in a user’s screen such that only one form of scrolling is required, then you are set.
Your goal is to accommodate a 320 CSS pixel vertical width. Or, 256 CSS pixel height.
Criterion 1.4.10 is extending the efforts made by criterion 1.3.1 Info and Relationships and 1.3.2 Meaningful Sequence in hopes of ensuring content and functionality are not lost. This time, it’s about resizing versus removing visual and layout styles. If your responsive breakpoints are such that a user needs to scroll in two directions to experience your content, then you need to update your code.
Success Criterion 1.4.13 Content on Hover or Focus
Do you provide popup content such as tooltips? You know when you hover over an image or text and you get additional information clarifying the image or text?
If you need to use this type of content delivery, WCAG 2.1 is recommending guidelines that will make such content easier to “see.” For example, when the popup tip appears, ensure that it remains until the user moves away from it. Also, don’t let the users' pointer block the content in the popup.
Not everyone can see small text. Not everyone can easily distinguish text from its colored background. WCAG 2.0 gave us three criterion to follow in an effort to accommodate such users of web content.
- 1.4.4 Text Resize
- 1.4.3 Contrast (Minimum)
- 1.4.6 Contrast (Enhanced)
In WCAG 2.1, the following are added to this list.
- 1.4.11 Non-text Contrast (AA)
- 1.4.12 Text Spacing (AA)
- 2.5.3 Label in Name (A)
Success Criterion 1.4.11 Non-text Contrast (AA)
You are already abiding by the contrast criterion for text and images of text if you are meeting WCAG 2.0. 1.4.11 makes some addition to contrasts.
First, you know when you hover over a button or link and it changes? That is a state change. You are going to need to ensure the change meets a 3:1 contrast ratio. Next, it’s not just about color on color but now there is a need to consider color next to the color.
The Understanding page for 1.4.11 gives examples such as pie charts and icons lined up next to each other. The potential design impacts discussed on this resource page are definitely worth a read.
Success Criterion 1.4.12 Text Spacing (AA)
Similar to 1.4.4 Resize text, 1.4.12 wants to ensure that changes in the spacing between lines, paragraphs, letters, or words, they won’t lose the content of functionality. So, you might need to check your CSS to ensure the following are possible:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Success Criterion 2.5.3 Label in Name (A)
This next criterion isn’t as direct as the last two when it comes to visibility of content, but reminds us of the fact that there is more than one way to “see.”
Depending on how your pages were made, you might have both visible and invisible labels on your site. Visible for those who can see the label, such a sign-up button, and invisible, a version of the label that assistive technology reads. Similar to when you create a link to a page and ensured the link and the page title were the same, visible and invisible labels need to match.
What happens when they don’t? A user speaks the label they see and their assistive technology looks for the same words. When visible and invisible labels differ, the technology can’t find what the user needs.
You don’t have to have the cognitive impairment not to understand something. In WCAG 2.0, three criterion are worth noting when it comes to easy-to-understand writing.
- 3.1.3 Unusual Words (AAA)
- 3.1.4 Abbreviations (AAA)
- 3.1.5 Reading Level (AAA)
Just because they are AAA level criterion, that doesn’t mean they should be dismissed. They are three of the easiest AAA criterion one can strive towards.
WCAG 2.1 has added the criterion that this reviewer feels fits with enabling users of your content to gain a better understanding of what it is you are conveying.
- 1.3.6 Identify Purpose (AAA)
- 4.1.3 Status Messages (AA)
- 2.3.3 Animation from Interactions (AAA)
Success Criterion 1.3.6 Identify Purpose (AAA)
It’s likely that you have at least one of the following on your site: user interface components (e.g., buttons, link, fields), icons, or regions. And, if you are following the requirements of 4.1.2 Name, Role, Value, you are defining most if not all of these.
However, what you might not be doing is providing information about what the component represents, such as an image link represents a link to the homepage. This criterion wants you to convey more than a name, even if the name seems to convey the applicable meaning. Remember, assistive technology is not Artificial Intelligence. It needs you to tell it what it can’t surmise on its own.
Success Criterion 4.1.3 Status Messages (AA)
If you are using a content management system designed for accessibility, like Drupal 8 for example, then you should be okay. If not, you will need to update your code to declare your system messages via a role or other appropriate properties that can be understood by assistive technology.
Success Criterion 2.3.3 Animation from Interactions (AAA)
Does this criterion address an interaction or is a cognitive distraction? Perhaps both.
Do you have things that move on your pages? Do objects fly in from the side as someone scrolls? Criterion 2.2.2 Pause, Stop, Hide from WCAG 2.0 applies when the page initiates an animated object. You might have heard of this one. 2.3.3 is intended to prevent animation from being displayed on the pages in the first place.
If you have a dynamic page with moving parts, you need to look into this one. You might need to add to existing animation controls and allow users to keep them from appearing. Of course, this is level AAA, but it’s worth considering as sudden movements can trigger vestibular (inner ear) disorders and cause dizziness, nausea, and headaches.
If you manage a federal site subject to Section 508, that doesn’t mean you shouldn’t take the additional 17 criterion into consideration when updating or building your site. As for everyone else, WCAG 2.1 is the recommended set of criterion. With the chance that someone might claim your site is non-compliant based on 2.1, you need to look into bringing your site up to date.
Remember, some of the new criteria are, by default, not going to be in play on your site. Many of them have to do with added bits of code that override default browser behavior that at one time were deemed acceptable. So, WCAG 2.1 doesn’t have to be scary.
Want to check if your website is compliant with web accessibility standards? Contact us today.