The Evolution of Accessibility Standards
In December of 2008, WCAG 2.0 was released and covered a wider “range of recommendations for making web content more accessible1.” In WCAG version 1.0 there were a series of guidelines that had checkpoints: priority 1, 2, or 3, that were the main basis for determining conformance. WCAG 2.0 differed in that a set of four design principles became the primary focus. These design principles, which have become the global standard for web accessibility state that a webpage must be:
- Perceivable – Information and user interface components must be presentable to users in ways they can perceive
Users must be able to perceive the information that is presented—info cannot be invisible to all of their senses.
- Operable – User interface components and navigation must be operable
A user must be able to operate the interface—the interface must not require interaction that a user can’t perform.
- Understandable – Information and the operation of user interface must be understandable
Users must be able to comprehend the information as well as the operation of the interface—content and/or operation cannot be beyond user understanding.
- Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technology
WCAG 2.0 was also divided into three level of conformance: A, AA, AAA based on the level of impact that each success criteria would have on the design or visual representation of a webpage. Conformance level A designates that there will be some impact on the design of a webpage, AA conformance will have a medium impact and AAA will have a high degree of impact on the design.
Six years after the release of WCAG 2.0, the accessibility working group of the W3C began developing WCAG 2.1 standards, which further expounds on the conformance requirements of version 2.0, which are grandfathered into version 2.1.
What’s New in WCAG 2.1
New Level A
1. 2.1.4 Character Key Shortcuts
Summary: Content creators are required not to use single-key shortcuts, or they must give the user a way to have them changed or turn them off.
2. 2.5.1 Pointer Gestures
Summary: *Requires that content creators ensure users can perform any touch functionality with the use of a single finger or assistive technology.
3. 2.5.2 Pointer Cancellation
Summary: Requires functionality that can be operated with a single pointer to use up-event triggering.
4. 2.5.3 Label in Name
Summary: Requires that any visible label that isn't part of the accessible name be required to be the trigger for speech activation.
Example: Users that rely on speech to navigate say “Click Next” if they can see a button labeled with the word “next.” If the button has an **aria-label= ”continue” then the “click next” command will not work because the assistive technology can’t see the accessible name. If the word “continue” was added to the string, aria-label= “Next, Continue,” then the user could say “click next” if the button is labeled “continue.”
5. 2.5.4 Motion Actuation
Summary: Requires that the motion functionality of a device or user motion (shaking, tilting, etc.) must also be usable with interface components.
New Level AA
1. 1.3.4 Orientation
Summary: *Content creators are required to not rely on screen orientation so that users who are not able to change their screen orientation can still use the website or application.
2. 1.3.5 Identify Input Purpose
Summary: *Requires form elements to have a way to map to purposes that map to the HTML autocomplete list, to enable assistive technology to identify and customize components, an add icons/symbols and present to disabled users.
3. 1.4.10 Reflow
Summary: *To support low vision users that enlarge text and read information in a single column, this criterion requires functionality that can be operated with a single pointer to use up-event triggering. (Enlarging without requiring horizontal scrolling.)
4. 1.4.11 Non-Text Contrast
Summary: Any visible label that is not part of the accessible name is required to be part of the string that the accessible name is composed of. (Any visual information must meet the same minimum contrast required for larger text.)
5. 1.4.12 Text Spacing
Summary: Users must be provided with a means to adjust text spacing for ease of readability.
6. 1.4.13 Content on Hover or Focus
Summary: If a user activates content (intentionally or otherwise) the interaction must be designed in a way that all users are able to operate it as well as perceive the content.
7. 4.1.3 Status Messages
Requires that if there is a change in the content that doesn’t change focus, users, specifically those using screen reader technology, should be provided with a status message.
New Level AAA
1. 1.3.5 Identify Purpose
Summary: The meaning of all controls (inputs and outputs), as well as all other key information, must be made available via technology.
2. 2.2.6 Timeouts
Summary: Users must be alerted to how much time they can be inactive before they may lose information that they have input.
3. 2.3.3 Animation from Interactions
Summary: Requires that users be provided with a means to turn off any unnecessary motion effects.
4. 2.5.5 Target Size
Summary: Requires that controls be made larger (*44 x 44 CSS pixels) to ensure that they can be easily operated particularly with touchscreen technology.
5. 2.5.6 Concurrent Input Mechanisms
Summary: Web content cannot restrict users from choosing a different means to input content.
*=With exceptions **= An attribute used to provide a text label for an object.
When to Implement WCAG 2.1
While WCAG 2.0 is the current standard that the US court system has adopted in light of the recent onslaught of website accessibility litigation, it would be wise to begin implementing version 2.1 guidelines as soon as it is possible, as it now encompasses the mobile technology that over 224.3 million people use every day.
1. Web Content Accessibility Guidelines (WCAG) 2.1 https://www.w3.org/TR/WCAG21/