WCAG 2.1: The final list of candidate Success Criteria is here
Comment period open until January 12, 2018
After 4 years of work, much research and public input, we're releasing our draft for wide review (this used to be called Final Draft) before moving into Candidate Recommendation for WCAG 2.1. We will not be reviewing any more Success Criteria for WCAG 2.1. There are 20 Success Criteria proposals (15 for those within levels A and AA) and a new conformance reporting proposal. Here's the breakdown and the links:
- 6 SCs at Level A
- 9 SCs at AA
- 5 SCs at AAA
How to comment?
The final draft before CR is W3C Working Draft December 7, 2017 of WCAG 2.1
Click a link to a Success Criterion in the table and ask yourself the following:
- Is it testable by expert human evaluation or automation?
- Is it implementable across technologies (or are exceptions sufficient)?
- Is it scalable across human languages?
- Could your organization implement 2.1? Why or why not?
- If not, do you have suggestions to improve it?
To comment, open a new issue on Github.
or email email@example.com
The Working Group plans to publish to Candidate Recommendation (CR) in January. The group plans to begin implementation testing with a goal to finalize WCAG 2.1 as a W3C Recommendation by mid 2018, so comments on this draft are critical.
New Success Criteria in WCAG 2.1
Below are the proposed new Success Criteria summarized in plain language. Note: The 63 Success Criteria from WCAG 2.0 are grandfathered into WCAG 2.1.
|Short Name (link to raw up to date version)||
Plain language summary of requirements
|Who does it help and how?||What we're looking for||SC #||Lvl|
|Identify Common Purpose||
Ensures common names are provided in one of the following ways:
his will enable future assistive technology to identify them, customise them, add icons or symbols, and present them to cognitive users.
|Users with cognitive disabilities, low vision and others who need to personalize the interface, either to simplify it, or another change.||Looking for feedback on definitions||1.3.4||AA|
|Contextual Information||Builds on the Level AA "Identify Common Purpose" and anticipates the release of Cognitive metadata that will be used by assisitve technology to personalize, and simplify user interfaces, so that assistive technology can identify them, customise them, add icons or symbols, and present them to cognitive users.||Users with cognitive disabilities, low vision and others who need to personalize the interface, either to simplify it, or another change.||(AT RISK of being removed if comments can't be resolved)||1.3.5||AAA|
Basically requires Responsive design (or a few tricks to get zoom to work)
|Users with low vision who need to make things larger. The content will wrap inside the viewport insead of causing horizontal scroll.||1.4.10||AA|
|Graphic Contrast (Minimum)||
Extends 3:1 contrast minimums to important graphical information, visible focus indicators and other interactive controls.
|Users with low vision and cognitive disabilities need help seeing or perceiving information in graphics, interactive components., and focus indicators.||We're interested in feedback on challenges evaluating images to determine what parts are required for comprehension of content, and whether the Understanding document clarifies how to resolve the challenges.||1.4.11||AA|
Requires author not to interfere with user style sheets and other CSS based client side interventions. Also, requires enough spacke around text that the spacing can be spread out a little bit.
|Users with low vision or cognitive disabilities who need to override the font, line spacing, paragraph spacing, color scheme etc.||We're seeking examples in the wild of text content outside of blocks of text where it would be impossible to meet this SC. The SC's scope may be narrowed based upon implementation testing.||1.4.12||AA|
|Content on Hover or Focus||
Requires hover effects like custom tooltips etc, not to obscure the trigger that activated them, and helps users move into the hover box without having it close on them.
Users with low vision who need to work without hover behavior obscuring content.
Authentication does not rely on memorization.
For cognitive users who have trouble with memorization
|(AT RISK of being removed if comments can't be resolved)||2.2.6||A|
Requires a mechanism to suppress or postpone interruptions and changes in content.
|Users with cognitive disabilities who need to work without interruptions.||(AT RISK of being removed if comments can't be resolved)||2.2.7||AA|
Requires authors to not use timeouts or save data to repopulate forms after timeout.
|Users with low vision and cognitive disabilities get extra time.||2.2.8||AAA|
|Animation from interactions||
Requires authors not to use motion as a result of a user clicking (or activating) something, or provide a way to turn it off. Addresses parallax scrolling and CSS animations etc.
|Users with vestibular disabilities (motion sickness) and those with cognitive disabilities who need to use the site without being triggered.||(AT RISK of being removed if comments can't be resolved)||
|Character key shortcuts||
Requires authors to not use single key shortcuts, or provide a way to turn them off or change them.
Shortcut keys that have a combination of keys are much less likely to be triggered this way.
Users of speech technology. (e.g., If the site hijacks "p" key for shortcut, when the user dictates words such as "happy" the shortcut can be triggered.)
|Label in Name||
Requires any visible label that is not the accessible name to be part of the string that makes up the accessible name.
An example, speech users say "click Go" if they see a button with the word "go" visually on it. If the button has an aria-label="submit" then that command will do nothing, and because the accessible name is not visible, the speech user wouldn't know what to say to press it.
|But if the word "go" was part of the string in the ACCNAME, (i.e, aria-label="Go, Submit" then saying "Click Go" would activate the button.||2.4.12||A|
|Pointer gestures||Requires authors to ensure the user can perform touch functions with assistive technology or one finger.||Users with dexterity disabilities, those who are blind or have other disabilities that interfere with the use of timed gestures, multi finger, or complex gestures. They can use simple pointer events.||2.5.1||A|
Requires authors to use up-event triggering (which is standard) on interactive components.
Users with dexterity disabilities who miss the target. It ensures the target is not triggered on touch down, but rather on touch up allow
ing them to move their finger away from the wrong target if they miss.
|Target Size||Ensures buttons, links and other interactive elements are 44x44px, with a list of exceptions for inline links, lists of links, in page links etc..||Helps those with dexterity disabilities hit the target.||2.5.3||AA|
|Target Size (no exceptions)||Same as above, removes exceptions||Helps those with dexterity disabilities hit the target.||2.5.4||AAA|
|Concurrent Input Mechanisms||
Ensures authors don't interfere with the way a user is accessing content. For instance don't disable mouse interaction is a user has a touch screen.
It doesn't require authors to do anything extra, just ensures they don't actively disable input modalities.
|Users who need a variety of ways to input due to repetitive strain, or are limited to one less common input way to interact with the computer.||2.5.5||AAA|
|Motion Actuation||Will require functionality from shaking, tilting etc., also be usable with interface components.||People who have a mounted device, or who cannot shake or tilt a device||2.6.1||A|
Requires authors not to rely on a screen orientation.
|Users who have their device mounted, or who cannot change orientation can still use the site even though they have a fixed orientation.||2.6.2||AA|
For HTML pages, when there is a visible status message, this requires authors to use aria-live roles or attributes to notify AT users when something on the page changes.
|Users of AT who can't see changes or have trouble perceiving changes on a page, such as shopping cart updates. Their AT will announce a short phrase about new content added to the page.||
The working group seeks input regarding the feasibility and applicability of complex gaming scenarios for this SC.
Other changes include:
- Clarification that page conformance requires each break point to conform, to remind stakeholders that mobile content needs to conform also.
- Addition to Optional Components of a Conformance Claim to include metadata about the accessibility features and level of accessibility of the document. This will help users with disabilities identify accessible ePub books online, and give search engines tools to find accessible content.
Breaking these up by Task Forces:
- Cognitive Task Force (5 New SC Proposals)
- 1 Level A
- 2 Level AA
- 2 Level AAA
- Low Vision Task Force (4 New SC Proposals)
- 4 Level AA
- Mobile Task Force (10 New Proposals)
- 5 Level A
- 3 Level AA
- 2 Level AAA
- Mobile conformance clarification that conformance is required at each breakpoint
- AD HOC: 1 level AAA
- ePub Task Force: 1 conformance addition
Feel free to comment on this article on Twitter @davidmacd
David MacDonald is a 15 year WCAG veteran and co-editor of Using WAI ARIA. Opinions are my own.
For a quote or just to chat about your organization's needs