You are currently viewing Success Criterion 2.5.1 – Pointer Gestures

Success Criterion 2.5.1 – Pointer Gestures

WCAG Principle: Operable

Guideline 2.5: Input Modalities (Make it easier for users to operate functionality through various inputs beyond keyboard).

Conformance Level: A (Minimal Requirement)

What is Success Criterion 2.5.1 (Pointer Gestures)?

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 success criterion recommends offering more than one way to control content. This is crucial because path-based gestures require specific start and end points. A typical example is when you pinch to zoom in on a map. If this is the only way to zoom, it causes problems for people with limited mobility or those who use adaptive devices. To accommodate them, consider providing simple alternatives that use single pointer actions (like a click or tap).

Note that this guideline does prohibit the use of complex gestures. Rather, it encourages web authors to use simpler alternatives to ensure everyone can use the website. The only exception to this rule is when a multipoint or path-based gesture is essential to the task. For example, signing a document digitally requires the path of the gesture (the signature).

How does it make your website accessible?

This WCAG guideline is part of a broader effort to ensure web technologies are accessible to all users. These include those with disabilities that affect their motor control and those who rely on different technologies to interact with digital content. By requiring alternatives to complex gestures, this success criterion helps create a more inclusive digital environment.

Who benefits from websites with alternatives to multipoint or path-based gestures?

  • People with limited fine motor skills.
  • Assistive technology users.
  • Older adults with reduced dexterity.
  • Users with temporary physical impairments, like a broken arm.
  • All website users also benefit from simpler interaction methods.

How to Meet Success Criterion 2.5.1 (Pointer Gestures)

Common mistakes on websites:

  • Adding functions that require users to use multipoint or path-based gestures without providing simple alternatives.
  • Implementing gestures that work on some devices but fail on others, especially touch screens.
  • Not considering how assistive technologies, such as head pointers, eye-gaze systems, or speech-controlled inputs will handle complex gestures.
  • Failing to test gestures across various devices and input methods to ensure accessibility.

How to fix these mistakes:

  • Ensure that all complex gestures, like pinch-to-zoom, have simple options such as single taps or clicks.
  • Implement gestures that work seamlessly across all devices, especially touch screens and desktops.
  • Design interactions that are easily accessible with assistive technologies such as head pointers, eye-gaze systems, and speech-controlled devices.
  • Test all gesture-based interactions on multiple devices and with different input methods to ensure accessibility.

Helpful tips for developers:

  • Use ARIA (Accessible Rich Internet Applications) to define roles and states for interactive elements. This ensures that assistive technologies understand your UI components.
  • Ensure that all functionalities are keyboard-accessible, including tabs, arrows, and shortcuts.
  • Make touch targets (buttons and links) large enough to be easily tapped, reducing the need for precision.
  • Conduct usability testing with users who have disabilities to identify and address real-world accessibility issues.

How to test if your websites meets conformance:

  • List all the elements on your website that require user interaction (buttons, sliders, carousels, etc).
  • Use a mouse (or a single finger on a mobile phone touchscreen) to interact with each element. Next, verify that you can perform all required actions with simple taps or clicks.
  • Identify if any interaction requires specific path-based gestures (e.g., swiping in a specific direction). Then, verify that you can also complete these interactions using single-point gestures.
  • Use assistive devices like head pointers or eye-gaze systems to test the interactions. Confirm that users can operate all functions without needing complex gestures.
  • Test the website on various devices, including desktops, tablets, and smartphones. Ensure that interactions are consistent across all devices.
If steps 2, 3, 4 and 5 are true, then the website meets this success criterion.

Bad and Good Examples (Code Snippets)

Code example that fails success criterion 2.5.1 (pointer gestures)

Code Snippet

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Inaccessible Map Example</title>
  <link rel="stylesheet" href="https://unpkg.com/leaflet@1.9.3/dist/leaflet.css" integrity="sha256-kLaT2GOSpHechhsozzB+flnD+zSSW1x9VXXXhRUCt3A=" crossorigin="" />
  <script src="https://unpkg.com/leaflet@1.9.3/dist/leaflet.js" integrity="sha256-WBkoXOwTeyKclOHuWtc+i2uENFpDZ9YPdf5Hf+D7ewM=" crossorigin=""></script>
  <style>
    #map-container {
      height: 500px;
    }

    #map {
      height: 100%;
    }
  </style>
</head>
<body>
  <div id="map-container">
    <div id="map"></div>
  </div>

  <script>
    let map = L.map('map').setView([51.505, -0.09], 13);

    L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
      attribution: '&copy; <a href="https://www.openstreetmap.org/copyright">OpenStreetMap</a> contributors'
    }).addTo(map);

    map.on('touchstart', handleTouchStart);
    map.on('touchmove', handleTouchMove);

    let touchStartZoom;
    let touchStartCenter;

    function handleTouchStart(e) {
      if (e.touches.length === 2) {
        touchStartZoom = map.getZoom();
        touchStartCenter = map.getCenter();
      }
    }

    function handleTouchMove(e) {
      if (e.touches.length === 2) {
        const touchEndZoom = touchStartZoom + (e.scale - 1);
        map.setZoom(touchEndZoom, { animate: false });
        map.panTo(touchStartCenter, { animate: false });
      }
    }
  </script>
</body>
</html>

In this example, we used the Leaflet library to render a map and handle touch events for pinch-to-zoom functionality. You’ll notice that the only way to zoom in or out of the map is by using a pinch gesture.

This fails the success criterion for pointer gestures because there isn’t an alternative method for zooming with a single pointer or keyboard. That means assistive technology users who can’t perform multi-point gestures won’t be able to zoom the map.

Code example that meets success criterion 2.5.1 (pointer gestures)

Code Snippet

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Accessible Map Example</title>
  <link rel="stylesheet" href="https://unpkg.com/leaflet@1.9.3/dist/leaflet.css" integrity="sha256-kLaT2GOSpHechhsozzB+flnD+zSSW1x9VXXXhRUCt3A=" crossorigin="" />
  <script src="https://unpkg.com/leaflet@1.9.3/dist/leaflet.js" integrity="sha256-WBkoXOwTeyKclOHuWtc+i2uENFpDZ9YPdf5Hf+D7ewM=" crossorigin=""></script>
  <style>
    #map-container {
      height: 500px;
      position: relative;
    }

    #map {
      height: 100%;
    }

    #zoom-controls {
      position: absolute;
      bottom: 10px;
      right: 10px;
      z-index: 1000;
    }
  </style>
</head>
<body>
  <div id="map-container">
    <div id="map"></div>
    <div id="zoom-controls">
      <button id="zoom-in">+</button>
      <button id="zoom-out">-</button>
    </div>
  </div>

  <script>
    let map = L.map('map').setView([51.505, -0.09], 13);

    L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
      attribution: '&copy; <a href="https://www.openstreetmap.org/copyright">OpenStreetMap</a> contributors'
    }).addTo(map);

    map.on('touchstart', handleTouchStart);
    map.on('touchmove', handleTouchMove);

    let touchStartZoom;
    let touchStartCenter;

    function handleTouchStart(e) {
      if (e.touches.length === 2) {
        touchStartZoom = map.getZoom();
        touchStartCenter = map.getCenter();
      }
    }

    function handleTouchMove(e) {
      if (e.touches.length === 2) {
        const touchEndZoom = touchStartZoom + (e.scale - 1);
        map.setZoom(touchEndZoom, { animate: false });
        map.panTo(touchStartCenter, { animate: false });
      }
    }

    const zoomInButton = document.getElementById('zoom-in');
    const zoomOutButton = document.getElementById('zoom-out');

    zoomInButton.addEventListener('click', () => {
      map.zoomIn();
    });

    zoomOutButton.addEventListener('click', () => {
      map.zoomOut();
    });
  </script>
</body>
</html>

In this updated version, we added two buttons for zooming in and out of the map. We placed these in the bottom-right corner of the map container and styled them using CSS. You’ll observe that the JavaScript code for handling pinch-to-zoom gestures remains the same, but we’ve added event listeners for the zoom buttons.

So, if a user clicks the “+” button, it calls the zoomIn() method, which zooms in one level. Similarly, clicking on the “-” button calls the zoomOut() method, which zooms out one level.

This code now meets WCAG success criterion 2.5.1 because it provides an alternative way to zoom the map. This helps users who cannot perform multi-point gestures to zoom in and out by clicking the buttons.

Frequently Asked Questions

What are multipoint or path-based gestures?

Multipoint or path-based gestures are user interactions that involve multiple points of contact or follow a specific path or movement pattern. They are often used on touch-enabled devices, such as smartphones, tablets, and touchscreen computers. These include tap, swipe, pinch-to-zoom and long press. 

What are some examples of acceptable alternative input methods?

Examples of acceptable alternative input methods are buttons, keyboard shortcuts, single-tap or click actions.

Is this success criterion only applicable to touch-enabled devices?

No, WCAG 2.5.1 applies to all websites and web applications, regardless of the input method or device used. It aims to ensure accessibility for users with various disabilities and assistive technologies.

How does WCAG 2.5.1 relate to other WCAG guidelines?

Success criterion 2.5.1 is closely related to other success criteria that address input modalities and control mechanisms. These include 2.1.1 Keyboard, 2.5.2 Pointer Cancellation, and 2.5.3 Label in Name. Providing accessible alternatives to complex gestures ensures content and functionality are usable by people with different abilities and input methods.

Ready To Become
Compliant?

Leave a Reply