WCAG for Mobile and Touch
The Web Content Accessibility Guidelines (WCAG) contain various requirements that are particularly relevant for operating websites and applications using touchscreens, pointer devices, and mobile devices. Key focus areas include the simple usability of gestures, avoiding unintentional actions, sufficiently large interactive elements, and flexible presentation on mobile devices.
2.5.1 Pointer Gestures – Level A
Principle
Functions that require a complex pointer gesture must generally also be operable with a simple pointer input. This includes multipoint gestures or path-based gestures, for example. Users should not be forced to execute a specific gesture with multiple fingers or along a specific trajectory.
An exception applies when the complex gesture is essential for the function itself.
Examples
- A map cannot be zoomed in or out exclusively using a two-finger gesture. Additional controls, such as plus and minus buttons, should be provided.
- An image carousel should not be operable exclusively through a specific swipe motion, but also via next and previous buttons, for example.
2.5.2 Pointer Cancellation – Level A
Principle
An action should not be triggered as soon as a pointer input begins. Users must have the ability to cancel an action that was started accidentally.
For touch operation, this means, for example: if a finger is placed on a button, the action should not execute at that exact moment. The action only occurs upon the corresponding confirming input, such as upon release.
Examples
- A button triggers its action only when the finger is released, not when it is first placed on the screen.
- If the finger is moved away from the button area after touching it, the action can be cancelled.
This significantly reduces operating errors, especially on touchscreens.
2.5.4 Motion Actuation – Level A
Principle
Functions triggered by device motion or user movement must also be available through an alternative control option. Furthermore, motion actuation must be capable of being disabled unless it is essential.
This is particularly relevant for mobile devices capable of detecting movement, tilting, or shaking, for instance.
Examples
- An application allows undoing an action by shaking the smartphone. An additional button should also be provided for this purpose.
- A function controlled by tilting the device must also be accessible via standard control elements.
2.5.7 Dragging Movements – Level AA
Principle
If a function requires a dragging movement, a control option without dragging must generally be available. Users should not be required to press and hold a pointer and move it across a specific path.
This criterion was introduced with WCAG 2.2 and is particularly relevant for touchscreens.
Examples
- A slider should not be operable solely by dragging the control thumb. Selecting an input by tapping the desired position can serve as an alternative control option.
- For a drag-and-drop list, additional options should be provided to move an entry using buttons such as "Move Up" or "Move Down".
The goal is to make functions accessible to individuals who find precise dragging movements difficult or impossible to perform.
Target Sizes and Layout on Mobile Devices
2.5.8 Target Size (Minimum) – Level AA
Principle
Control elements operated with a pointer—such as a finger on a touchscreen—must be sufficiently large or have adequate spacing from other targets.
WCAG 2.2 generally requires a minimum target size of 24 × 24 CSS pixels or a correspondingly large spacing between smaller targets. Exceptions exist for specific cases, such as links placed directly inline within text.
For particularly comfortable operation, a larger target size of 44 × 44 CSS pixels is frequently recommended.
Examples
- Small icons like "Delete", "Close", or "Menu" should not be only a few pixels in size; they should possess a sufficiently large clickable area.
- Two adjacent buttons should be arranged so that they are not accidentally tapped at the same time on a smartphone.
1.3.4 Orientation – Level AA
Principle
Websites and applications must not restrict their usage exclusively to a single display orientation. Content should therefore be usable in both portrait and landscape orientation.
A restriction is permissible if a specific orientation is essential for the function.
Examples
- A website should not function exclusively in portrait mode unless there is a technical or content-related necessity for it.
- Conversely, an application featuring a virtual piano keyboard may rely on a specific orientation if it is required for its intended usage.
1.4.10 Reflow – Level AA
Principle
Content must be able to adapt to narrow screens without requiring users to scroll horizontally for standard usage. This is an essential foundation for responsive web design.
The requirement applies, among other things, to a display presentation equivalent to a width of 320 CSS pixels.
Examples
- A longer piece of text should automatically reflow vertically on a smartphone instead of requiring a horizontal scrollbar.
- A table or complex layout should be designed so that content can be displayed and operated meaningfully even on a narrow screen.
Summary
The key core principles for operation on mobile devices and touchscreens can be summarized as follows:
- Avoid complex gestures: Functions should not be accessible exclusively via multi-finger or path-based gestures.
- Make actions cancellable: Accidental touch input should not trigger an action immediately.
- Avoid dragging: Functions typically operated by dragging require an alternative input option.
- Supplement motion control: Shaking, tilting, or other motions must not be the sole control option.
- Provide sufficiently large targets: Control elements must be reliably reachable on touchscreens.
- Enable flexible presentation: Content should adapt to different screen sizes and orientations.
More on Components
- Semantic and Machine Readibility for Accessibility
- Understanding Keyboard Accessibility
- Why CAPTCHA's are not accessible
- Erros in native Apps
- Trigger Warnings in digital Accessibility
- How to make Timeouts accessible
- The Accessibility of Disabled Buttons
- Accessibility for Animations and Motion
- Integrated Text versions, style switchers and magnification
- How to make chatbots accessible
- Some Thoughts on Real Time Information Accessibility
- Hiding Content from Screen Readers
- Accessibility Problems with Infinite Scrolling
- Making Labels accessible
- Focus Management
- Accessibility of interactive maps
- Making dynamic Content accessible