Pointer and Motion Accessibility

Why it matters

When a function exists only behind a gesture, the people who cannot perform that gesture lose the whole function, not just a convenience. That includes people with tremor or limited dexterity, people who touch the screen with one finger or a mouth stick, people who use eye tracking or a head pointer, and people whose tablet is mounted on a wheelchair in one fixed orientation. Accidental activation hurts too: if Delete fires the moment a finger touches the screen, one slip deletes data.

For the product, all of these criteria are required for WCAG 2.2 Level AA conformance, the level most organisations and contracts target, and 2.5.7 Dragging Movements is new in 2.2, so designs that were approved against WCAG 2.1 may never have been checked for it. For the tester, the defects are easy to miss: on a desktop with a mouse, or on your own phone, the gesture works for you. You have to test deliberately for the people who cannot make it.

Pointer gestures and pointer cancellation (2.5.1, 2.5.2)

2.5.1 Pointer Gestures (Level A) covers multipoint gestures, which need two or more fingers at once (pinch to zoom, a two-finger swipe), and path-based gestures, where the path of the movement matters and not only its start and end (a swipe in a given direction, drawing a shape). Every such function must also work with a single pointer and no path: a tap, a click, a double tap or a long press. A map with pinch-to-zoom passes when it also has + and − buttons; a carousel that moves only by swiping fails. The exception is a gesture that is essential, such as drawing your signature, where the path itself is the input; if the drawing only acknowledges something, a button would do, so it is not essential. The criterion covers gestures the page itself interprets: the browser’s own pinch zoom and the screen reader’s gestures are out of scope.

2.5.2 Pointer Cancellation (Level A) protects against accidental activation. For any function operated with a single pointer, at least one of these must hold: the down-event (the moment the button or finger goes down) runs no part of the function; the function completes on the up-event and can be aborted before or undone after; the up-event reverses whatever the down-event did; or completing on the down-event is essential. Native buttons and links already behave well: click fires after release, so pressing, sliding off the control and releasing does nothing. The defect appears when a developer attaches the action to pointerdown, mousedown or touchstart. Pressing a key of an on-screen keyboard or keypad counts as essential.

• Gestures: list every swipe, pinch, two-finger and drawing interaction in the feature, then find the single-pointer way for each one and actually use it.
• Cancellation: press on every control that performs an action, move the pointer or finger off it, and release; nothing may happen. Start with delete and payment actions.
• Drag and drop counts too: picking an item up on the down-event is fine, as long as releasing it outside any drop target cancels the move.

// Defect (2.5.2): the item is deleted the moment the pointer goes down
deleteButton.addEventListener('pointerdown', deleteItem);

// Expected: click fires after release, and not if the pointer slid off the button
deleteButton.addEventListener('click', deleteItem);

Dragging movements and target size (2.5.7, 2.5.8)

2.5.7 Dragging Movements (Level AA) is new in WCAG 2.2. A dragging movement is pressing on an element, moving the pointer and releasing at another point, where only the start and end points matter: reordering a list, moving a card between columns, moving a slider thumb, panning a map. Every such function needs a way that works with single pointer actions and no drag, unless dragging is essential or the browser provides the behaviour and the author has not changed it.

Note what does not count: keyboard support. A slider that responds to the arrow keys meets 2.1.1 Keyboard, but a person using a head pointer, or a mouse with a tremor, is still a pointer user and may still be unable to drag. The alternatives must be real controls that meet 2.5.8 Target Size (Minimum) (Level AA): at least 24 by 24 CSS pixels, or enough spacing, with the exceptions taught in the visual accessibility guide. A 16-pixel Move up arrow squeezed against Move down replaces one failure with another. 2.5.5 Target Size (Enhanced), at Level AAA, asks for 44 by 44.

• Sortable list: Move up and Move down buttons on each row, or a Move to menu.
• Kanban board: select the card, then choose the target column from a menu or tap the column.
• Slider: a tap or click on the track moves the thumb to that value, or − and + buttons, or a number field next to it.
• Map: arrow buttons to pan, + and − buttons to zoom.

Motion actuation and orientation (2.5.4, 1.3.4)

2.5.4 Motion Actuation (Level A) applies when moving the device (shake to undo, tilt to scroll) or moving in front of a camera (wave to go to the next page) operates a function. Two things are required: the same function is available through an ordinary on-screen control, and the response to motion can be turned off, so that a tremor or a bumpy bus ride does not trigger it. There are two exceptions: motion used through an accessibility supported interface (this covers the ordinary movements of operating a keyboard, a mouse, a touch screen or an assistive technology), and motion that is essential to the activity, such as a step counter. This is motion as input; animation on the screen and the reduced-motion preference were covered with visual accessibility.

1.3.4 Orientation (Level AA) says content must not restrict its view and operation to portrait or landscape unless a specific orientation is essential; the examples WCAG gives include a bank check, a piano application, slides for a projector or television, and virtual reality content. A person whose tablet is fixed to a wheelchair cannot rotate it to suit your page. A layout that changes between orientations is fine and expected; the failure is a page that refuses to work, shows only a "Please rotate your device" message, or turns its content sideways. When you test, switch the device’s rotation lock off first, otherwise a pass means nothing.

Where an orientation lock usually hides (search the code and config):

CSS       @media (orientation: landscape) { main { display: none; } }
JS        screen.orientation.lock('portrait')
Manifest  "orientation": "portrait"             (installed web app)
Android   android:screenOrientation="portrait"   (AndroidManifest.xml)
iOS       UISupportedInterfaceOrientations       (Info.plist, portrait only)

Testing with a mouse, a touch device and device emulation

Use all three inputs, because each one finds different defects. Start with the mouse on a desktop: it is precise, so it shows whether every function has a single-click path. Move to a real phone or tablet for gestures, motion and rotation. Use browser device emulation in between to check phone-width layouts quickly, but never as the final word on touch or sensors.

• Mouse: complete every drag, swipe and pinch function with single clicks only; press, move off and release on every control that performs an action; measure small targets in devtools.
• Touch device: perform each gesture, then find and use its tap alternative; touch a button, slide your finger off and lift; shake and tilt where a feature reacts to motion, then switch the motion response off in the settings; turn rotation lock off and rotate on every screen, including open dialogs.
• Device emulation: in Chrome DevTools the device toolbar (Ctrl+Shift+M, or Cmd+Shift+M on a Mac) sets a phone viewport, simulates touch with the mouse and has a rotate button, and the Sensors panel sets device orientation values. Firefox’s Responsive Design Mode also offers a phone viewport, touch simulation and a rotate button. Watch for alternatives that the phone layout hides, such as carousel arrows that disappear below a breakpoint (the width at which the layout switches).
• Limits of emulation: it changes what the page is told, such as the viewport, touch events and, with a device preset, the User-Agent string (the text in which the browser names itself, its version and its operating system), not the hardware. It cannot shake a phone, it does not show how a real finger covers a small target, and the real operating system’s rotation behaviour can differ. Paste navigator.userAgent from the console into a User-Agent parser and you will see the session claim to be a phone while it runs on desktop hardware. Confirm every pass on at least one real device.
• Record with each result: device and OS, browser, the input used (mouse, finger or stylus), orientation and rotation lock state. A short screen recording makes gesture defects reproducible.

Try it: User-Agent Parser Try it: Test Case Generator

Worked example: testing a task board

A team ships a mobile-friendly task board. Cards move between columns by dragging, a swipe left on a card archives it, shaking the phone undoes the last change, and the delete icon on a card reacts on touch.

The tester runs the session from the previous section and records what passed as well: the board’s zoom works with + and − buttons as well as pinch (2.5.1), and the column header buttons measure 32 by 32 CSS pixels (2.5.8). Then the tester writes these defects, each with the criterion and the expected behaviour:

• "Card can be moved between columns only by dragging; no single-pointer way": fails 2.5.7 (AA). Expected: a Move to menu on each card, or select the card and then tap the column.
• "Archive is available only by swiping left": fails 2.5.1 (A), because a swipe is a path-based gesture. Expected: an Archive item in the card menu.
• "Shake to undo has no on-screen Undo and cannot be turned off": fails both requirements of 2.5.4 (A). Expected: an Undo button after each change and a setting that disables shake.
• "Card deleted on touchstart; sliding the finger off does not cancel": fails 2.5.2 (A). Expected: delete on release, ideally with Undo.
• "Board shows a rotate-to-portrait message in landscape on tablets": fails 1.3.4 (AA); a task board has no essential orientation.

Try it: AI Bug Title Generator

Frequently asked questions

References

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024The W3C Recommendation that defines the testable success criteria for accessible web content, organised under four principles and three conformance levels (A, AA, AAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)The informative explanation of each WCAG 2.2 guideline and success criterion: intent, who benefits, examples and techniques (not normative).
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)A filterable checklist of every WCAG 2.2 success criterion with its sufficient techniques and common failures.
• What are browser developer tools? — MDNMDN Web Docs (Mozilla)An introduction to the developer tools built into browsers — the inspector, the JavaScript console and the debugger — for examining a page while testing it.