EN 301 549 -- Mobile Gesture Alternatives

For reference only -- not part of a11ybot's automated checks.

What It Is

Clause 11 of EN 301 549 scopes accessibility requirements for software, including native mobile apps [1]. Gesture alternatives live specifically at clause 11.2.5.1 Pointer Gestures: any software function operated by a multipoint or path-based gesture -- pinch, two-finger rotate, three-finger swipe, edge-swipe -- must also be operable with a single pointer and without a path, unless the gesture is essential to the function. The clause text mirrors WCAG 2.5.1 Pointer Gestures [2] and binds it to the full software stack, not just web content.

Why It Matters -- the input-path mechanism

Mobile platform assistive technologies -- iOS VoiceOver, iOS Switch Control, iOS AssistiveTouch, Android TalkBack, Android Switch Access, head-pointer and eye-tracker drivers -- intercept direct touch and synthesise events through the platform accessibility API. The events they generate are single-pointer taps, activations, and custom accessibility actions. They do not generate synchronised multi-finger contacts or continuous path data. A pinch-to-zoom handler that reads two simultaneous UITouch objects, or an Android gesture detector watching for a two-finger fling, will never fire for a Switch Control user no matter how the user navigates the screen.

This is a mechanism, not a preference. Users with tremor, limited dexterity, a single functional hand, a mouth-stick, or a head-pointer physically cannot produce two synchronised contacts on a touchscreen. The platform AT closes the gap by exposing single-pointer alternatives -- but only for handlers that route through the accessibility tree. A gesture handler bound directly to raw touch events is invisible to the AT path and has no fallback unless the app provides one.

What the clause actually requires

EN 301 549 clause 11.2.5.1 adopts the WCAG 2.5.1 outcome verbatim for software: multipoint and path-based gestures must have a single-pointer, pathless equivalent unless the gesture is essential. "Essential" is narrow -- signature capture and handwriting recognition qualify, "we built it this way" does not. Accessibility Standards Canada's plain-language rendering of clause 11 confirms this reading (Accessibility Standards Canada, EN 301 549 clause 11 Software).

Clause 11.2.5.1 is the direct regulatory hook in EU procurement for mobile gesture alternatives. The related WCAG criterion 2.5.7 Dragging Movements [3] covers the adjacent problem -- drag-only interactions that a single-pointer user cannot complete -- and is worth designing against even though it is not pulled into EN 301 549 as a standalone software clause in the current version.

What to build

  • For every pinch, rotate, or multi-finger gesture, ship a visible single-tap control (zoom buttons, rotate-left/rotate-right buttons, a "reset view" affordance).
  • Replace drag-to-reorder with a tap-to-pick-up / tap-to-drop pattern, or expose reorder as a custom accessibility action on each list row.
  • Register gesture equivalents with the platform accessibility API: UIAccessibilityCustomAction on iOS, ViewCompat.addAccessibilityAction() or an AccessibilityDelegate on Android. A Switch Control or TalkBack user then reaches the action through the rotor or actions menu.
  • Do not make an edge-swipe the only path to navigation drawers, back, or dismiss. Pair it with an on-screen button that routes through the accessibility tree.
  • Test the build with Switch Control (iOS) and Switch Access (Android) enabled, then with VoiceOver and TalkBack. If a gesture has no single-pointer route through the accessibility tree, it fails 11.2.5.1.

Related pages

Sources

  • ETSI, EN 301 549 V3.2.1 Accessibility requirements for ICT products and services, clause 11.2.5.1 Pointer Gestures [1].
  • Accessibility Standards Canada, EN 301 549 -- 11 Software, plain-language rendering of clause 11.
  • W3C, Understanding Success Criterion 2.5.1: Pointer Gestures [2].
  • W3C, Understanding Success Criterion 2.5.7: Dragging Movements [3].