Forms
Dragging may be the only way to use this
WCAG 2.2 success criterion 2.5.7 Dragging Movements (Level AA)
- WCAG 2.2
- 2.5.7 Dragging Movements
- Also maps to
- 2.1.1 Keyboard
- Level
- AA
- Default severity
- Needs review
- Available in
- Free
Updated for Lumtera 1.2.2 and Lumtera Pro 1.1.1.
Why does it matter?
Drag-and-drop lists, sortable galleries and custom sliders are hard or impossible for people who use a head pointer, eye tracking, voice control or a shaky hand. WCAG 2.2 asks for another way that works with single clicks or taps.
Who it affects: Screen reader users, voice-control users who say a field's label to move to it, and people with memory or attention difficulties who lose a placeholder once they type.
What does Lumtera flag?
Markup that shows something can be dragged: draggable="true", jQuery UI sortable and draggable classes, SortableJS markers, or a list of data-id items with a drag handle. Also custom sliders (role="slider") that cannot take keyboard focus, so they can probably only be set by dragging. One finding per list or widget, each for review, since the markup cannot show whether another way exists.
Check ID drag-without-alternative — use it to filter the content report or with wp lumtera issues --rule.
How do I fix it in WordPress?
Make sure every drag action has a simple alternative: "Move up" and "Move down" buttons for sortable lists, or clicking an item and then clicking where it should go. For sliders, let visitors click a point on the track or use a number field, and make the slider focusable with the arrow keys. Then try it yourself with only the keyboard (Tab, Enter and the arrow keys) and with single clicks. If the plugin providing this feature has an accessible mode or setting, turn it on.
Example
<ul class="ui-sortable">
<li>Step one</li>
<li>Step two</li>
</ul>
<ul class="ui-sortable">
<li>Step one <button type="button">Move down</button></li>
<li>Step two <button type="button">Move up</button></li>
</ul>
How do I check the fix?
- Update the post. The issue disappears from the Lumtera Accessibility sidebar on the next check, and from the site report on the next scan.
- Click each field's label: the cursor should move into the field. With a screen reader, each field should announce its label when it receives focus.
Find this issue across your whole site
Lumtera runs this check in the block editor sidebar as you write, in the Elementor panel, in Review mode on the live page, and across the whole site in the content report and with wp lumtera scan. You can change its severity or turn it off in Lumtera → Settings.
Related checks
-
WCAG 4.1.2 · AError
Form field has no label
-
WCAG 1.3.1 · ANeeds review
Form field has more than one label
-
WCAG 1.3.1 · ANeeds review
Options are not grouped with their question
-
WCAG 1.3.5 · AATip
Personal-data field has no autocomplete
-
WCAG 3.3.7 · ATip
Form asks for the same email twice
-
WCAG 3.3.8 · AAError
Password field blocks pasting or password managers
Start with the free plugin today
All 69 content checks and 33 whole-page checks, fixes you approve with undo, and the site report — free, with no account and no page limits.