Implications of new input modes (touch, speech, gestures) for the Web Content Accessibility Guidelines

14. June 2014

Currently, the WCAG Working Group ponders what changes should be made in the next version of the Web Content Accessibility Guidelines (WCAG).

Author: Detlev Fischer (@wcagtest)

One driver for changes to WCAG is the assessment that user requirements linked to some types of disability have not been given enough prominence so far. For example, many accessibilty aspects that are very important for low vision users such as 1.4.3 Contrast, 1.4.4 Resize text and 2.4.7 Focus visible are required only on level AA of WCAG, not on the core level A.

Some authors outside the WCAG Working Group have recognised such imbalances and suggested changes. For example, Jared Smith's WCAG next proposes, among other sensible suggestions, to raise the Success Criteria 1.4.3 Contrast and 2.4.7 Focus Visible to level A. Others have argued that the current focus on technical accessibility is too narrow: see, for example, Brian Kelly's Response to the WCAG-EM 1.0 Working Draft.

New interaction modes: touch, speech, gestural input, and more

Another driver for changes to WCAG is the growth of new interaction modes, especially on mobile devices. The WCAG Principle 2: Operable focuses entirely on keyboard access since for the accessibility of desktop PCs, this mode is of vital importance both for users with motor impairments as well as for blind and low vision users.

In the meantime, touch input has become a major interaction mode, speech input is becoming more important too, and physical gestures (shaking a handset) and 3D gestural input are picking up.

For WCAG, one way to reflect this growing diversity of input modes would be to specify more mode-specific success criteria, e.g. 2.1.3 Touch, 2.1.4 Speech, etc. This however may prove unworkable. The question then remains how the growth of different input modes can adequately be reflected under Principle 2: Operable.

An input mode-agnostic Success Criterion under Principle 2: Operable?

After floating the idea of adding further mode-specific Guidelines and Success Criteria under Principle 2, several people from within the WCAG Working Group have expressed that this would probably be a bad idea, and that IndieUI Events will provide a generalised way of expressing functional operability. Indie UI defines a mapping of platform-specific and mode-specific input events to generic user intents (scrolling, panning, activating a link, cancelling an action, etc) which web applications can then interpret. Seen from this perspective, the mode-specific Success Criterion 2.1.1 Keyboard might now be considered a historic mistake and should be replaced by a more generic Success Criterion that is mode-agnostic.

I get the point, but I am not convinced that such a mode-agnostic Success Criterion would be easy to understand and apply by authors and evaluators. For the sake of concretion, let's call it 2.1.1 Accessible modes of input: Make all functionality available via mode-specific user interaction events that map onto accessibility APIs.

Granularity and testability

What would a mode-agnostic umbrella Success Criterion like 2.1.1 Accessible modes of input mean for the WCAG requirement that Success Criteria should be testable? From the point of view of testing, existing umbrella Success Criteria like 1.3.1 Info and Relationships that lump together diverse specific requirements simply have the wrong level of granularity. Some of the requirements may be highly important (use h1-h6 to identify headings) others fairly minor (use semantic markup to emphasise text) and all of them requiring different tests. And WCAG stresses that no test of any specific Technique on its own can establish a Failure to conform to a Success Criterion.

Having umbrella Success criteria means that the gap between Critera and Techniques to explain what they mean in practice is widening. A number of hands-on accessibility testing schemes have found it necessary to estabish a layer of topic-specific checkpoints to bridge the gap: AccessiWeb in France, BITV-Test in Germany, Drempelvrij in the Netherlands, and so on. This indicates that from a practical perspective of applying the guidelines to web content, WCAG often misses the mark by being too general on the level of SC and too specific on the level of technique.

The context for determining conformance

To determine the conformance of content to the sketched new umbrella Success Criterion 2.1.1 Accessible modes of input, one would probably need to define interaction modes that the content under review must and should support. For example, while no one would argue that an intranet-based account management system used exclusively on desktop PCs should meet all touch input requirements to conform, a public facing web app supporting small screens should probably be required to provide full access to its content via touch gestures and be keyboard-operable as well.

How far such a definition would or should go in enumerating targeted user agents, interaction modes, or audiences is anyone's guess. In any case, the actual diversity of content types, user agents and interaction modes makes it ever harder to retain the assumption that WCAG Success Criteria are technology- and user agent-agnostic.

A better match of WCAG Success Criteria and Techniques

If the testability of Success Criteria remains a core concept of WCAG, we need to ensure that Success Criteria are expressed on a level of granularity that affords an good match with Sufficient Techniques below. The BBC's Mobile Accessibility Guidelines are admirable in this respect, helped by choosing a narrower scope than WCAG.

Introducing mode-specific Success Criteria under Principle 2: Operable would be advantageous in this respect. A generic Success Criterion that lumps together the diverse input modalities would mean that on the next level down, there is likely to be an enormous and heterogenous grab bag of Techniques for keyboard, touch, speech and gestural interaction, with complex dependencies.

It is unclear how these Technques would be structured to communicate what would constitute conformance for a particular type of content, and what might be called a Common Failure. Take a minute to look at How to meet Success Criterion 1.3.1 Info and Relationships , the umbrella criterion we already have, and tell me if you think this is usable advice.

Disclaimer: In this text, I speak as an individual, not as a member of the WCAG Working Group. This is just food for thought. Comments are welcome.

Comments

Comment by Patrick H. Lauke |

Interestingly, I've just recently worked on scrubbing a set of accessibility advice documents we're maintaining for one of our clients of "keyboard"; specific language, where appropriate. For instance, we often talk about "keyboard focus", but the same sort of action (navigating sequentially in source order) can also be performed on touchscreen devices with screen readers (swiping left/right to set the focus in sequence). We've resorted to talking about things like the aforementioned sequential navigation, browser focus cycle, etc, and avoiding "keyboard" as much as possible to make it more generic. Incidentally, particularly for the touchscreen+screenreader scenario, a lot of suggested approaches (custom keydown/keypress handling, for instance) fall completely flat. Also, apart from tabindex=0 and tabindex=-1, the attribute has no effect (at least from my testing) in mobile browsers with SRs. so, a lot of rethinking in certain areas may well be needed.

Write a comment