2.5 Input Modalities (Level A)

Why is it important to allow for multiple input modes?

A keyboard was the first input mode for accessing a computer. The mouse was then introduced, greatly improving navigation through web content — for those who could operate a mouse. Various other mouse-like input devices soon followed, like track pads, track balls, eye-gaze pointers, speech control, joysticks, and various other input methods that mimic mouse functions.

Then, mobile devices with touch screens came along and introduced a new range of input methods — these are typically referred to as gestures. Gestures include physical movements like tapping, double tapping, pressing and holding, swiping, dragging, and so on.

Needless to say, limiting input modes can greatly reduce the number of people who are able to use a site. Fortunately, in many cases, designing for both mouse and keyboard access will also allow other input modes. A tap, for instance, is possible for elements that can be clicked with a mouse. A swipe function is much like Tab key navigation. However, it is when developers create custom elements in which mouse and/or keyboard access are scripted that input modes may be limited.

Pointer Gestures Explained

With the introduction of smartphones and touch pads, multipoint gestures have become fairly common place. A multipoint gesture typically requires two or three fingers to perform the gesture. One example is a pinch zoom, placing two fingers on a device screen and spreading them apart, causing the screen to magnify. Some people will not be able to perform such a gesture, so some other means is needed to zoom, such as [-] or [+] buttons that zoom with a single tap or click. Single-point gestures will be more accessible to some and can often be mimicked with a keypress.

These are some examples of multipoint and single-point gestures:

Multipoint gestures:

• Two-finger pinch
• Split tap
• Two- or three-finger taps and swipes.

Single-point gestures:

• Tap
• Double tap
• Press and hold
• Focus and gaze (eye tracking)

Another type of gesture is a path gesture. In the case of a path gesture, users draw a pattern to unlock a screen, or they drag a slider thumb to select a value along a particular range. In both cases, some people will not be able to click-and-drag or point-and-drag, so an alternative will be required. For a slider, users should be able to click on any spot along the slider, and, with a single click, they move the slider thumb to a select position along the slider bar. Users should also be able to control the slider thumb using a keyboard, though this is covered by SC 1.3.1 Keyboard (Level A).

Swipe gestures can also be difficult for some people. For example, a photo gallery may use a swipe to navigate from one image to the next. Next and Previous buttons or links can be added to the gallery viewer so those who are unable to swipe can click. Next and Previous buttons, with some scripting, can also be associated with left and right arrows on the keyboard, so those unable to swipe or point and click can also operate the gallery with a keypress.

This success criterion applies to web content rather than operating system–level gestures. For example, Android phones may have users draw a pattern to unlock the phone. In this case a preference setting is available to switch to a code or to use a fingerprint scanner instead of drawing the pattern. In this case, an operating system–level path gesture can be replaced with a single point method of unlocking the phone.

Pointer Cancellation Explained

The aim of this success criterion is to prevent accidental pointer input, whether through a mouse click or through a touch gesture to activate web content. For instance, by default, activation of a link or button occurs when a click is released or when a finger is lifted. In both cases, it gives a user an opportunity to abort the click or press by moving the pointer away from the element that was clicked before releasing it.

In most cases, activation should not occur during the down action (e.g., mousedown, touchstart); rather, it should occur when the action is released (e.g., mouseup, touchend). One exception occurs in cases where a down-event pops open a dialog, which closes when the up event occurs. Drag-and-drop elements also activate on the down action, i.e., holding down the element while it is moved. Then, the up action occurs when the element is in its new location. In this case, users should be able to release the action outside the allowable drop zone to abort, which returns the element to its initial location.

There are other conventional behaviours that also rely on a down-event, such as typing letters into a form field or clicking a key on a piano app. In such cases, it would be counter-intuitive to have the action occur on the up-event.

Label in Name Explained

This success criterion ensures that people who are using speech input or text-to-speech output are able to draw a connection between what they see on the screen and what their assistive technology reads to them. Assistive technologies read the “accessible name” associated with interface elements, which can be assembled with text gathered from a number of sources, such as a role (e.g., menuitem), state (e.g., enabled), and properties (e.g., haspopup menu) associated with the element, in addition to the text displayed on the screen. The W3C defines “accessible name” as follows:

For those using speech input through voice recognition software, they may encounter a form button created using an image, and in that image is the word “search.” They can speak the word “search” to activate the button but only if the alt text for the image is the same as the text in the button image. In this case, alt is the accessible name, joined with the role “button.”

On the other hand, a developer might also include additional information in a title attribute for the button, with words such as “enter keywords or phrases.” This text is hidden by default but displays when a mouse pointer hovers over the button. For a speech input user, they see the word “search” in the image, though in this case the accessible text would be “enter keywords and phrases.”

As a result of the accessible name differing from the text label for the button, a speech user may be unable to activate the button, in which the visible button text (“search”) and the accessible name (“enter keywords or phrases”) differ. In this case, the text in the button image should be prefixed on the title text. So you end up with an accessible name like “search: enter keywords and phrases.” In this case, the user can speak the word “search” to send focus to the button via its title text.

<button title="Search: enter keywords or phrases">
<img src="search_icon.png" alt="Search">
</button>

Screen reader support for HTML title attribute

*Despite a setting to read title text, title text is not read by JAWS 18

**When title text is present for linked images, title is read, and alt is not read.

Motion Actuation Explained

Most smartphones today include sensors, such as an accelerometer and/or gyroscope, that detect motion of the device. For example, they would detect shaking, which might act as an undo function. Some phones can also detect user gestures through the device’s camera, such as a hand wave to turn the page of an electronic book for instance.

Some people, however, who are unable to move the device (e.g., if it is attached to a wheelchair) or are unable to produce gestures (e.g., are unable to use their hands), will need alternative means of activating these functions. In the case of the undo function, there may be a button alternative that can be pressed when the device is stationary. Or, in the case of an electronic book, speech might be used to turn the page, to tap on the right side of the screen, to swipe left, and so on.

Likewise, motion actuation needs to be an option that can be disabled. If, for instance, a user has a shaky hand, they may inadvertently activate motion-based functions. They may need to disable motion activation. For any function that is activated via motion, an alternative means of activating the function is required that does not require moving the device or gesturing to it.