In June 2018, the World Wide Web Consortium (W3C) unveiled the latest update to the Web Content Accessibility Guidelines with the release of WCAG 2.1. WCAG 2.1 is now the official recommendation of the W3C. Let's take a look at what's new in WCAG 2.1.
It’s been 10 years since the initial WCAG 2.0 were released. 10 years is a very long time in the digital realm. It’s a testament to the quality of the guidelines they remained unchanged for so long.
The aim of WCAG 2.1 is to further improve the accessibility of content across the web and ensure a complete experience for all users regardless of any disability. WCAG 2.1 builds on and extends WCAG 2.0, all WCAG 2.0 success criteria are included in WCAG 2.1 with the same number and same wording. As well, the level of conformance continues to be A, AA, or AAA.
What’s New in WCAG 2.1?
So what’s new in WCAG 2.1? There are 17 additional success criteria to address the following:
- mobile accessibility
In 2008, when WCAG 2.0 was released, the majority of users were surfing the web using their desktop computers and the guidelines were html focused. Smart phones just weren’t that smart yet. Of course, the world surfs differently now and mobile accessibility is an important consideration. - people with low vision
It’s estimated 246 million people have low vision. WCAG 2.1 puts in motion guidelines to help users with low vision have a better web experience. - people with cognitive and learning disabilities
Implementing techniques to help those with cognitive and learning disabilities will make sites easier for all users.
Let’s review the additional guidelines at a high level.
1.3.4 Orientation (Level AA)
The guideline states content should not restrict view and operation to a single display operation such as portrait or landscape. Ensure your content responds to the user’s device orientation and is displayed correctly. Some users, for example, may have their device in a fixed position, for example attached to a wheel chair, and will have difficulty viewing your content if it doesn’t display correctly.
1.3.5 Identify Input Purpose (AA)
Use techniques to identify the purpose of form fields. Where possible, help the user by providing auto fill to facilitate the completion of online forms.
1.3.6 Identify Purpose (AAA)
This guideline states the purpose of interface components, icons and key sections should be identified within your code.
Examples include
- identify regions in a page so users can hide areas or move between regions
- provide text alternative to icons so screen readers can be used to facilitate understanding for those with visual challenges
- Mark up icons on a website so users can substitute their own icon set
1.4.10 Reflow (AA)
Have you ever visited a website on your phone, for example, and noticed you have to move the screen left or right to read the full content? It’s cumbersome and difficult. It certainly makes it more difficult to read the page.
This guideline addresses the issue. It requires content be presented without loss of information or functionality or requiring scrolling in 2 dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels.
The intent is to support people with low vision who need to enlarge text and read it in a single column. At the same time, this guideline will benefit all users as it ensures the content is provided in an easy to view format.
If you have a truly responsive website design, you will likely be meeting this requirement.
1.4.11 Non-Text Contrast (AA)
High contrast between text elements has been part of WCAG 2.0, this guideline extends the requirement to include buttons, text, and graphical images.
1.4.12 Text Spacing (AA)
The intent of this guideline is to ensure users can override text spacing to improve their reading experience. Some users, with dyslexia for example, will create their own style sheet to assist their ability to view a site. If you site doesn’t support this, the user may have difficulty viewing your site and leave.
1.4.13 Content on Hover or Focus (AA)
This guideline specifically addresses trigger content such as tooltip, modal window, etc. Where a these exist, three conditions must exist:
- Dismissable: user must be able to dismiss the content without moving pointer unless the content is an error message or does not obscure existing content.
- Hoverable: If pointer triggers additional content then pointer can be used without the content disappearing. For example, a trigger might present additional content where the user must scroll to read the entire message. Scrolling, in this case, should not cause the additional content to disappear.
- Persistent: the additional content remains visible until the user selects to dismiss it or if the information is no longer relevant (for example, error code).
2.1.4 Character Key Shortcuts (A)
The guideline refers to the implementation of keyboard shortcuts. Where keyboard short cuts are implemented in a site, at least one of the following conditions must be met:
- A mechanism is provided so the shortcut can be disabled
- A mechanism is provided to allow the user to remap the shortcut to non-printable keyboard characters such as CTRL, ALT, ESC, etc.
- The keyboard shortcut is provided only when the component is in focus.
2.2.6 Timeouts (AAA)
Where timeouts are used, ensure users are warned that inactivity will cause data loss.
2.3.3 Animation from Interactions (AAA)
The guideline requires users be provided with the ability to disable motion animations triggered by interaction. The exception is where the animation is essential to the information being presented.
2.5.1 Pointer Gestures (A)
The intent of this guideline is to ensure content can be operated using simple gestures on multiple devices. For example, not all users can easily use two fingers to zoom. Where content requires complex gestures there must also be a simple method provided, for example double tap, long press, etc.
2.5.2 Pointer Cancellation (A)
Where the user is required to interact with the screen using a single point (one click, long press, tap) at least one of the following must be true:
- Execution of the action must not be trigged on the down event
- Completion of the action is to be trigged on the up event and there is a mechanism to cancel the function or undo afterwards.
- Up event reverses any outcome
- Where the down event is used to call the function there must be an important reason
2.5.3 Label in Name (A)
User interface components with labels that include text or images of text should have the name set to the text presented. Following this guideline will make your site more accessible to users who use screen readers.
2.5.4 Motion Actuation (A)
Where functionality is triggered by device motion, for example shaking your phone, there exists user interface components, such as button or text input, to generate the same outcome.
Motion can be disabled to prevent accidental motion except where:
- The motion is used to operate functionality through an accessible interface
- The motion is essential for the function
2.5.5 Target Size (AAA)
This guideline requires a clickable element on a page be at least 44 x 44 CSS pixels except when:
- The element is available though an equivalent link or control on the same page that is at least 44 x 44 CSS pixels
- The element is a sentence or block of text
- The size of the target is controlled by the device (for example radio buttons, check boxes, etc.)
- The presentation of the element is essential to the information being conveyed.
2.5.6 Concurrent Input Mechanisms (AAA)
The intent of this guideline is to allow users to switch between different methods of input when interacting with content. Some users may find it easier to switch from a keyboard to voice input, for example, when completing a form. This guideline states that you must support this type of interaction.
4.1.3 Status Messages (AA)
The intent of the guideline is to ensure users are aware of important changes to content in a way that doesn’t interrupt the flow of their work. The intended beneficiaries are vision challenged users of assistive technologies with screen reader capabilities. Essentially, where content changes, for example selecting “submit” on a form, ensure appropriate tagging so assistive technologies communicate the status to the user.
What’s Next for WCAG2.1?
WCAG 2.1 will continue to evolve and increase to fully meet the needs of people with disabilities. The guidelines may evolve into WCAG 2.2 or the name may be changed to Silver.
The task force working on the evolution of the guidelines is called the Silver Task Force. The symbol for silver from the periodic table is AG and, of course, we know AG as Accessibility Guidelines; hence the same Silver Task Force.
