Compliance

Simplifying the New WCAG 2.1 Guidelines

Share this post:

Recommendations for new accessibility guidelines were released on January 30, 2018 by the World Wide Web Consortium (W3C). In this new draft version of the Web Content Accessibility Guidelines (WCAG), none of the current 2.0 Success Criteria have been altered. Instead, 17 additional criteria have been recommended for 2.1.

This article is intended to help you grasp the objective of each of these 17 new recommendations. The below table gives a simplified one-sentence “pitch” of the intent, as well as indicating which users are expected to benefit the most from its implementation. [Update: the info was grouped into paragraphs until we can resolve a responsive design oddity with the table.]

Once you absorb this brief introduction, follow the links to the actual wording of the draft on the W3C website. You’ll find the text of the Success Criteria provide many additional nuances and qualifications, which were debated by the working group for 2.1 for over a year. Since the resulting language must be fully testable, it is sometimes hard to quickly understand the end objective of a Success Criterion, hence my simplified list.

If you want more insight, read the Understanding documents, which are linked from each Success Criterion, for in-depth explanations for the intent of each new requirement. Note that these Understanding documents are actively being drafted, so consider them “in progress”.

1.3.4 Orientation (Level AA)
Don’t lock content to either portrait or landscape presentation.
Key intended beneficiaries: users unable to modify the orientation of devices

1.3.5 Identify Input Purpose (Level AA)
Make the meaning of common inputs available via technology.
Key intended beneficiaries: users with some cognitive disabilities

1.3.6 Identify Purpose (Level AAA)
Make the meaning of all controls (not just inputs) and other key information available via technology.
Key intended beneficiaries: users with some cognitive disabilities

1.4.10 Reflow (Level AA)
Ensure content can be enlarged without requiring horizontal scrolling.
Key intended beneficiaries: low-vision users

1.4.11 Non-Text Contrast (Level AA)
Ensure important visual information such as graphics and icons meets the same minimum contrast that is required for larger text.
Key intended beneficiaries: low-vision users

1.4.12 Text Spacing (Level AA)
Let users adjust text spacing to make it easier to read.
Key intended beneficiaries: users with some cognitive or low vision disabilities

1.4.13 Content on Hover or Focus (Level AA)
If content can appear or disappear without a user intentionally activating it, design the interaction in such a way that all users can operate it and perceive the content.
Key intended beneficiaries: low-vision and blind users

2.1.4 Character Key Shortcuts (Level A)
Ensure custom shortcuts include, or can be made to include, a modifier key.
Key intended beneficiaries: users primarily operating via speech or keyboard

2.2.6 Timeouts (Level AAA)
Tell users how long they can be inactive before they may lose information.
Key intended beneficiaries: users with some cognitive disabilities

2.3.3 Animation from Interactions (Level AAA)
Allow users to turn off unnecessary motion effects.
Key intended beneficiaries: users with vestibular dysfunction

2.5.1 Pointer Gestures (Level A)
Let users operate touchscreens with a single finger.
Key intended beneficiaries: users with some physical disabilities

2.5.2 Pointer Cancellation (Level A)
Reduce accidental activation of controls by making their operation consistent.
Key intended beneficiaries: users with some cognitive, physical or visual disabilities

2.5.3 Label in Name (Level A)
Let the visual label for controls be a trigger for speech activation.
Key intended beneficiaries: users operating via speech

2.5.4 Motion Actuation (Level A)
Don’t rely solely on device motion to control page content.
Key intended beneficiaries: users unable to physically manipulate devices

2.5.5 Target Size (Level AAA)
Make controls bigger so they can be operated more easily, especially on touch screens.
Key intended beneficiaries: users with some physical disabilities

2.5.6 Concurrent Input Mechanisms (Level AAA)
Don’t prevent users from choosing different ways of inputting content.
Key intended beneficiaries: users requiring specific means of operation or using assistive technology

4.1.3 Status Messages (Level AA)
Let assistive technologies notify users about changes to the content that don’t take focus.
Key intended beneficiaries: blind and low vision users

The latest draft, which in W3C terminology is called the Candidate Recommendation, will now go through a six-month review and testing process in preparation for official release. For more background on the objectives and timing of WCAG 2.1, see the Candidate Recommendation’s Introduction section. [July 31 update. The numbering and SC naming was updated to match that in the published Recommendation in June].

More Compliance stories
By Ram (P G) Ramachandran and Thomas Brunet on May 16, 2018

AI-Enabled Tools and Automation to Improve Accessibility

Try Automated Accessibility Tools wth Unlimited Scans through June The IBM Accessibility Research team is laser-focused on seamlessly integrating accessibility into the development process. We have developed a suite of IBM Automated Accessibility Tools to help development teams easily and effortlessly “make accessibility happen.” Teams that use our tools tell us: “The automated tests run […]

Continue reading

By Marc Johlic and Sharon Snider on May 14, 2018

Updates to the Va11yS Open Source Project

  With Global Accessibility Awareness Day (GAAD) quickly approaching, Sharon and I thought it would a be a good time to give you a brief update on our open source Verified Accessibility Samples project – or Va11yS.  Jack Dam, our Accessibility Test Engineer, has been rigorously testing the latest samples and adding the results for […]

Continue reading

By Tom Babinszki on September 11, 2017

Maximizing Impact with Personalized Accessibility Training

There are many outstanding accessibility tutorials online. Yet, I’m finding that designers and developers are reluctant to go through them. I always wondered why? As I travel to many different IBM offices around the world training product design and development teams and understanding their needs, I believe I have found what makes them more interested […]

Continue reading