Understanding Success Criterion 2.5.1: Pointer Gestures

Success Criterion 2.5.1 Pointer Gestures (Level A): 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.

This requirement applies to web content that interprets pointer actions (i.e. this does not apply to actions that are required to operate the user agent or assistive technology).

Intent

The intent of this Success Criterion is to ensure that content can be operated using simple inputs on a wide range of pointing devices. This is important for users who cannot perform complex gestures, such as multi-point or path-based gestures, in a precise manner, either because they may lack the accuracy necessary to carry them out or because they use a pointing method that lacks the capability or accuracy.

Examples of path-based gestures include swiping, dragging, or the drawing of a complex path. Such paths may be drawn with a finger or stylus on a touchscreen, on a graphics tablet or trackpad, or with a mouse, joystick, or similar pointer device. A user may find it difficult or impossible to accomplish these if they have impaired fine motor control, or if they use a specialized or adapted input device such as a head pointer, eye-gaze system, or speech-controlled mouse emulation.

Examples of multi-point gestures include a two-finger pinch zoom, a split tap where one finger rests on the screen and a second finger taps, or a two or three finger tap or swipe. A user may find it difficult or impossible to accomplish these if they type and point with a single finger or stick, in addition to any of the causes listed above.

Authors must ensure that their content can be operated without such complex gestures. When they implement multi-point or path-based gestures, they must ensure that the functionality can also be operated via single-point activation. Examples of single-point activation on a touchscreen or touchpad include taps, double taps, and long presses. Examples for a mouse, trackpad, head-pointer, or similar device include single clicks, click-and-hold and double clicks.

The success criterion applies to author-created gestures, as opposed to gestures defined on the level of operating system or user agent. An example for gestures provided on the operating system level would be swiping down to see system notifications, and gestures for built-in assistive technologies (AT) to focus or activate content, or to call up AT menus. An example of user agent-implemented gestures would be horizontal swiping implemented by browsers for navigating within the page history, or vertical dragging to scroll page content.

While some operating systems may provide ways to define "macros" to replace complex gestures, content authors can not rely on such a capability because is not pervasive on all touch-enabled platforms. Moreover, this may work for standard gestures that a user can predefine, but may not work for other author-defined gestures.

This Success Criterion does not require all functionality to be available through pointing devices, but that which is must be available to users who use the pointing device but cannot perform complex gestures. While content authors may provide keyboard commands or other non-pointer mechanisms that perform actions equivalent to complex gestures (see Success Criterion 2.1.1 Keyboard), this is not sufficient to conform to this success criterion. That is because some users rely entirely on pointing devices, or find simple pointer inputs much easier than alternatives. For example, a user relying on a head-pointer would find clicking a control to be much more convenient than activating an on-screen keyboard to emulate a keyboard shortcut, and a person who has difficulty memorizing a series of keys (or gestures) may find it much easier to simply click on a labeled control. Therefore, if one or more pointer-based mechanisms are supported, then their benefits should be afforded to users for users through simple, single-point actions alone.

An exception is made for functionality that is inherently and necessarily based on complex paths or multi-point gestures. For example, entering one's signature may be inherently path-based (although acknowledging something or confirming one's identity need not be).

Benefits

Examples

Related Resources

Resources are for information purposes only, no endorsement implied.

Techniques

Each numbered item in this section represents a technique or combination of techniques that the WCAG Working Group deems sufficient for meeting this Success Criterion. However, it is not necessary to use these particular techniques. For information on using other techniques, see Understanding Techniques for WCAG Success Criteria, particularly the "Other Techniques" section.

Sufficient Techniques

  • GXXX: Do not rely on path-based gestures

  • GXXX: Do not rely on multi-point gestures

  • GXXX: Provide controls that do not require complex gestures and perform the same function as complex gestures

  • GXXX: Single-point activation for spatial positioning and manipuation

Advisory Techniques

Although not required for conformance, the following additional techniques should be considered in order to make content more accessible. Not all techniques can be used or would be effective in all situations.

None

Failures

The following are common mistakes that are considered failures of this Success Criterion by the WCAG Working Group.

  • Functionality can be operated by pointer input but not with single-point activation alone

Key Terms

essential

if removed, would fundamentally change the information or functionality of the content, and information and functionality cannot be achieved in another way that would conform

functionality

processes and outcomes achievable through user action

single pointer

new

pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses, and path-based gestures