In January 2018, the hard work of W3C resulted in its new Web Content Accessibility Guidelines (WCAG) 2.1 standard reaching Candidate Recommendation stage. This means that, barring any significant issues in its real-world testing, the standard is close to completion and on track for its mid-2018 release date.
Last year I wrote an article titled WCAG 2.1 draft: reflections on the new guidelines and success criteria. It’s fair to say that a lot has changed since then and that is ultimately a good thing. Importantly, the purpose of WCAG 2.1 is NOT to replace the well-established WCAG 2.0 standard, but rather to extend support for the mobile web. In my view, WCAG 2.1 as it stands does this very well with some additional success criteria added to existing guidelines, and a much-needed focus on supporting mobile platforms by providing two new guidelines.
With WCAG 2.1 reaching a near-complete stage its a great time to look at all this in a bit more detail and focus on what additional work would be required by ICT professionals to meet WCAG 2.1 Level AA compliance.
Before we get started, it’s important to highlight two things: firstly, I’m not going to go through all the guidelines and success criteria associated with WCAG 2.0, just the WCAG 2.1 extensions. If you’d like more information on the original WCAG 2.0, I’d be happy to provide you with some resources to get up-to-date with the international standard.
Secondly, I’m going to focus particularly on Level AA compliance. A number of the new WCAG 2.1 success criteria are Level AAA so for now I’ll leave those out given most policy and legislative frameworks don’t go to Level AAA.
Two new guidelines
So with those things in mind, let’s start with the two new guidelines. The addition of the guidelines brings the total in WCAG 2.1 to 14 with both guidelines sitting under the Operable design principle. The new guidelines are:
- 2.5 Pointer Accessible: Make it easier for users to operate pointer functionality.
- 2.6 Additional sensor inputs: Ensure that device sensor inputs are not a barrier for users.
Guideline 2.5 is focused on making sure that whatever type of pointer is being used, such as a mouse pointer, a finger interacting with a touch screen, an electronic pencil/stylus or a laser pointer, all functions should work correctly. It may be the case that a person with a disability finds it easier to use one type of pointing device over another, so from an accessibility standpoint all options should be available.
Guideline 2.6 relates to the use of sensor inputs such as a gyroscope or accelerometer found on mobile devices. From an accessibility standpoint, it may be the case that users can’t operate these sensors such as the inability to tilt a mobile phone if it is mounted on a wheelchair. As such, it is essential that people with disabilities are able to achieve the same outcome through the user interface if they are unable to use a sensor-based input method.
In addition to the two new guidelines, there are also new success criteria that have been added to existing guidelines. The following is a list of all Level A and AA WCAG 2.1 success criteria extensions.
WCAG 2.1 Level A
Success Criterion 2.4.11: Character Key Shortcuts
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:
- Turn off
- Active only on focus
Success Criterion .2.4.12: Label in Name
For user interface components with labels that include text or images of text, the name contains the text presented visually.
Success Criterion 2.5.1: Pointer Gestures
All functionality that uses multipoint or path-based gestures for operation can be operated with a single pointer without a path-based gesture, unless a multipoint or path-based gesture is essential.
Success Criterion 2.5.2: Pointer Cancellation
For functionality that can be operated using a single pointer, at least one of the following is true:
- No Down-Event
- Abort or Undo
- Up Reversal
Success Criterion 2.6.1: Motion Actuation
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
- Supported Interface
These essential WCAG 2.1 success criteria demonstrate the importance of catering for people with disabilities on the mobile platform. Success criteria 2.4.11 and 2.4.12 add additional support in helping users navigate and find content by ensuring that customised keyboard shortcuts don’t interfere with assistive technology and improvements in labelling identification. The two success criteria 2.5.1 and 2.5.2 explain the importance of making sure that multi-gesture commands can be achieved using a pointer and that there is a consistent technique to cancel the action. The final success criteria in this list, 2.6.1, explains that the commands reliant on the movement of a device should also be achievable through the standard user interface.
One of the concerns that has been raised through the WCAG 2.1 process is that several of these success criteria have an ‘essential’ element which is viewed by many as a way in which developers can avoid the need to implement accessibility with the justification being that the design is essential to the functionality of the web content. However, I suspect in practical terms it will be difficult for a developer to argue that other accommodations are not possible if it is obvious that alternative interface controls could have addressed the issue, so it will be interesting going forward to see under what circumstances the ‘essential’ argument is put forward as a way of avoiding some WCAG 2. success criteria.
WCAG 2.1 Level AA
Success Criterion 1.3.4: Identify Common Purpose
The meaning of each input field collecting information about the user can be programmatically determined when:
- The input field has a meaning that maps to the HTML 5.2 Autofill field names; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
Success Criterion 1.4.10: Reflow
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels;
Except for parts of the content which require two-dimensional layout for usage or meaning.
Success Criterion 1.4.11: Non-Text Contrast
The visual presentation of the following have a contrast ratio of at least 3:1 against adjacent color(s):
- User Interface Components
- Visual information used to indicate states and boundaries of user interface components, except for inactive components or where the appearance of the component is determined by the user agent and not modified by the author;
- Graphical Objects
- Parts of graphics required to understand the content, except when a particular presentation of graphics is essential to the information being conveyed.
Success Criterion 1.4.12: Text Spacing
In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
Word spacing to at least 0.16 times the font size.
Exception: Human languages and scripts which do not make use of one or more of these text style properties in written text can conform using only the properties that are used.
Success Criterion 1.4.13: Content on Hover or Focus
Where receiving and removing pointer hover or keyboard focus triggers additional content to become visible and hidden, respectively, the following are true:
Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.
Success Criterion 2.6.2: Orientation
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
While many of the success criteria here may initially appear difficult to implement, the bundling of 1.4.x success criteria together make it helpful in understanding that these are all related to visual improvements. I’m particularly pleased to see that the issue of the infamous ‘double scrollbar’ scenario that screen magnification users face so often, particularly on small displays, is addressed to some degree here along with contrast elements, text scaling and hover issues. It is interesting to note again as to the remarkably specific level of detail in some of these success criteria and it’ll be interesting to see if the real-world testing confirms these values prior to the final WCAG 2.1 release.
I’m also pleased to see Orientation make it this far, and out of all the new success criteria I suspect this will be the thing that resolves the most frustration for people with disabilities overall on a mobile device. When a mobile website or app forces the user to use their device in portrait or landscape for no apparent reason it is a great frustration and significantly affects how the device can be used as it can change the reach of buttons, make swipe gestures more awkward or affect the use of screen real estate. While there is another ‘essential’ statement creeping in here, it’s been my experience that there are few apps that lock in an orientation that really need to do so, which leads me to be optimistic about the implementation of this one.
Where to from here?
From here, it’s likely that WCAG 2.1 will be released this year as promised, and the take-away message for ICT professionals is to get ready to consider the access implications of mobile-specific elements suchas multiple input methods and sensor integration. For accessibility professionals, the biggest message here is that testing the accessibility of web content on a mobile device is no longer optional and new testing processes will need to be established.
That said, it’s been exciting through my W3C work to see the standard being developed and I’d like to say a big thank you to all the W3C staff, invited experts and volunteers who continue to give up their time to ensure that the mobile web receives a much-needed accessibility focus through the development of WCAG 2.1.
NOTE: at this time of writing, WCAG 2.1 is a Candidate Recommendation and is NOT an official W3C standard. As such, the guidelines and success criteria discussed in this article may differ from the final W3C recommendation.