What's new in WCAG 2.1, the web Accessibility Standard
WCAG 2.0 vs WCAG 2.1
After 4 years of work, the Accessibility Guidelines Working Group (AGWG) of the W3C is proud to release our Recommendation for WCAG 2.1 June 5, 2018. Here's the breakdown:
- 5 SCs at Level A
- 7 SCs at AA
- 5 SCs at AAA
W3C encourages organizations and individuals to review and update their policies to reflect the updated guidance provided by WCAG 2.1, in order to address more user needs in their websites.
Below are Level A and AA Success Criteria in one table followed by a separate table of Level AAA. This will help organizations targeting Level AA to see the new requirements quickly.
New Level A and AA Success Criteria in WCAG 2.1
Below are the 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 it in the WCAG)||
Plain language summary of requirements
|Who does it help and how?||Lvl|
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.||AA|
|1.3.5||Identify Input Purpose||Ensures form components have a programmatic way to map
to purposes that map to the HTML autocomplete
. The only way to do that now is actually adding HTML
auto-complete tokens to form fields. There is work being done
to develop special attributes in the future.
|This will enable future assistive technology to identify components, customise them, add icons or symbols, and present them to users with cognitive disabilities, low vision, who need to personalize or simplify the interface in different ways.||AA|
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 instead of causing horizontal scroll.||AA|
Extends 3:1 contrast minimums to important graphical information, visible focus indicators and other interactive controls when those indicators are necessary to identify the control as interactive.
|Users with low vision and cognitive disabilities need help seeing or perceiving information in graphics, interactive components., and focus indicators.||AA|
Requires author not to interfere with user style sheets and other CSS based client side interventions. Also, requires enough space 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.||AA|
|1.4.13||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.
Popup content must be hoverable, persistent as long as mouse is over the popup content, dismisable with ESC.
Users with low vision who need to work without hover behavior obscuring content.
|2.1.4||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.)
|2.5.1||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.||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 allowing them to move their finger away from the wrong target if they miss.
|2.5.3||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. Example of Label in Name
|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.||A|
|2.5.4||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||A|
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 visible status messages on a page, such as shopping cart updates. Their AT will announce the status message that was visibly added to the page.||AA|
New Level AAA new Success Criteria in WCAG 2.1
|Short Name (link to it in the WCAG)||
Plain language summary of requirements
|Who does it help and how?||SC #||Lvl|
|Identify Purpose||Builds on the Level AA "Identify Common Purpose" and anticipates the release of Cognitive meta-data that will be used by assisitve technology to personalize, and simplify user interfaces, so that resistive 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.||1.3.6||AAA|
|Timeouts||Users are warned of the duration of any user inactivity which could cause data loss, unless the data is preserved for more than 20 hours of inactivity||Helps users with cognitive disabilities and those with disabilities that woukd cause them to take a break from an activity.||2.2.6||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.||
|Target Size||Addresses hand tremors and mobile environments||Helps users who have tremors and dexterity problems by making interactive targets bigger.||2.5.5||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.||
Other changes include:
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.
A clarification that WCAG must be met at each breakpoint in a responsive site.
Breaking these up by Task Forces:
- Cognitive Task Force (3 New SC)
- 1 Level AA
- 2 Level AAA
- Low Vision Task Force (4 New SCs)
- 4 Level AA
- Mobile Task Force (9 New SCs)
- 4 Level A
- 2 Level AA
- 3 Level AAA
- AD HOC: 1 level AAA
- ePub Task Force: 1 conformance addition
How to comment?
WCAG 2.1 is complete, but we're working on 2.2 to be completed in about 2 years, so feel free to help us improve. To comment, open a new issue on Github.
or email firstname.lastname@example.org
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