How to test 2.5.7 Dragging Movements

The third in our series of articles on how to test the new Success Criteria (SC) in WCAG 2.2.

Detailed conformance and testing information can also be found in KnowledgeBase, a digital accessibility repository available through TPGi’s ARC Platform. KnowledgeBase is maintained and consistently updated by our experts, and can be accessed by anyone with an ARC Platform subscription. Contact us to learn more about KnowledgeBase or the ARC Platform.

Success Criterion 2.5.7 Dragging Movements is concerned with interfaces that use pointer dragging movements, such as drag and drop or custom sliders, and requires that they can also be operated by a single pointer without dragging movements.

Even the simplest dragging motion needs quite precise pointer control. You have to be able to touch or click down, then hold that pressure while you move the pointer, and then release it in a precise location. This may be difficult or impossible for users who have issues with fine motor control, or who use assistive technology that simulates pointer movement.

Normative requirements

All functionality that uses a dragging movement for operation can be achieved by a single pointer without dragging, unless dragging is essential or the functionality is determined by the user agent and not modified by the author.

This applies to any author-created content that handles pointer interactions. It doesn’t apply to interactions that are handled by the browser or system itself, such as dragging a scrollbar, or a native range input. Although if the author has applied any styles or scripting to that range input, then it would be covered by this SC, because it’s no longer not modified.

Keyboard accessibility is not a sufficient alternative to dragging movements. All interactive content must be keyboard accessible, or an alternative provided which is, but that in itself is not enough to conform to this SC, which is solely concerned with pointer interaction.

There are very few situations in which dragging movements are essential, since in almost all cases, the dragging movements are simply the means to an end, not the end in itself. However one possible exception would be an online mobility test, that asks you to perform specific dragging movements, in order to test whether you can. There are also potential gaming applications that could be considered essential exceptions, and that would be a judgment call.

Practical ambiguities

The existing SC 2.5.1 Pointer Gestures doesn’t apply to dragging movements, because they’re not multipoint or path-based gestures. With drag and drop for example, you grab an element at one location (Point A) and then drop it somewhere else (Point B), but the path your pointer takes to get from A to B is not significant. Only the end point matters, therefore it’s not a path-based motion.

The term single pointer also bears some examination. It’s currently defined like this:

Pointer input that operates with one point of contact with the screen, including single taps and clicks, double-taps and clicks, long presses […]

This definition doesn’t seem to include simulated pointer inputs, generated by voice control or other assistive technology, since they don’t have a point of contact. Yet single pointer accessibility is of great benefit to this group of users, for example where spoken Click [thing] commands manifest as simulated single clicks. The understanding docs also mention several such technologies, including eye-tracking and speech-controlled mouse emulators, as being embraced by the intent of this SC.

It seemed to me like a contradiction. However on further reading (thanks Pat) the concept of pointer itself is defined in the Pointer Events specification:

A hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.

So a pointer is defined by coordinate systems, not by hardware (or fingerware). This makes it clear that all forms of pointer input are included, whether or not they were generated by a physical pointer, and the glossary definition of single pointer is to be clarified and updated quite soon.

Testing barriers

Testing this SC requires the ability to perform pointer dragging movements, in order to identify and assess any content that uses them. Therefore manual testing can’t be solely done by engineers who are unable to perform those actions.

Automated testing

This SC can’t be tested by automation.

Testing draggable content requires complex manual interactions, which can’t be fully emulated in a realistic manner. And the extent to which they can be emulated would essentially invalidate the test, since testing by emulation is as much a test of the emulation, as the thing it’s emulating (which is a kind of observer bias).

Relevant content may not be identifiable anyway. Drag and drop widgets might use the draggable attribute, but they might also use entirely custom code, that’s not identifiable from the markup. Even if it was identifiable, there’s no way to readily determine whether it supports single pointer interaction.

I suppose it might be theoretically possible to create a script analyzer, that scans and executes JavaScript code to identify the patterns of interaction it supports. However currently, as far as I know, this doesn’t exist.

Manual testing

Manual testing can be performed in the following steps:

1. Identify the presence of content that uses pointer dragging movements (e.g., drag and drop, drag sorting, custom sliders and carousels).
2. Ignore those where (either):
   • functionality is provided by the browser or system, and not modified by the author (e.g., unstyled native sliders, page or overflow scrolling);
   • the dragging movement is essential (e.g., mobility test);
   • equivalent functionality (which does not rely on pointer dragging movements) is available elsewhere.
3. Verify that these interfaces can be used by a single pointer without dragging movements, for example:
   • drag and drop can be operated by point-and-click, or targets have actionable menus;
   • drag sorting includes up/down buttons, or position number inputs;
   • sliders can be moved by clicking the track, or they have left/right buttons;
   • carousels include previous/next buttons, or slide number inputs.

Yielding one of three expected results:

• Pass: All author content which uses pointer dragging movements can be operated with a single pointer without dragging movements, or an exception applies to content which requires dragging movements.
• Fail: Some web content requires the use of pointer dragging movements, and no exceptions apply.
• Not Applicable: No web content uses pointer dragging movements.

Glossary

• Functionality
• Dragging movement
• Pointer
• Single pointer
• Essential
• User agent
• Normative

Resources

• Designing a reorderable list component
• Understanding SC 2.5.7: Dragging Movements (Level AA)
• Pointer Events (Level 2)
• Accessibility Testing with WCAG 2.2 (Webinar Video)
• Accessibility Testing with WCAG 2.2 (Webinar Transcript)
• New Success Criteria in WCAG 2.2

Image credit: Heidi De Vries.