Skip to content

Category: Web Content Accessibility Guidelines

A11y 101: 2.5.7 Dragging Movementsdragon statue on buddhist temple rooftop

A11y 101: 2.5.7 Dragging Movements

Published on March 30, 2026

Picture this: You’re trying to reorder items in a list. The interface wants you to click, hold, drag the item to a new position, and release. Seems intuitive, right? Now imagine you have a tremor in your hand, or you’re using a trackpad with limited precision, or you’re navigating with a single switch device. Suddenly, that “simple” drag-and-drop becomes an exercise in frustration.

This is exactly what WCAG 2.5.7: Dragging Movements is trying to fix.

Dragging Isn’t Universal

The rule says:

Any functionality that requires dragging movements (click-and-hold, drag-to-reorder, swipe-to-delete, etc.) must also be operable with a single pointer action without dragging.

In plain English: If you can do it by dragging, you should also be able to do it by clicking, tapping, or using buttons.

Precision Isn’t Everyone’s Friend

Dragging movements assume a level of motor control that not everyone has:

  • Fine Motor Impairments: Users with conditions like Parkinson’s, cerebral palsy, or arthritis may struggle with the sustained pressure and precise movement dragging requires.
  • Assistive Technology Users: Switch devices, eye-tracking systems, and head pointers often can’t perform traditional drag operations.
  • Temporary Disabilities: A broken wrist or sprained finger can turn a simple drag into an impossible task.

The goal of 2.5.7 isn’t to eliminate drag-and-drop. We’re trying to ensure that everyone has a way to accomplish the task, regardless of their physical abilities.

Focus on User Needs

When you design a feature that only works with dragging, you’re implicitly saying: “If you can’t drag, you can’t use this.” That’s not a UX decision. It’s a decision to exclude users.

Ask yourself: If I were navigating this site with a single switch, would I be able to reorder this list? If the answer is “no,” you aren’t just failing a criterion; you’re failing the person who needs the feature the most.

Common Pitfalls (And How to Fix Them)

I’ve seen this fail in a few classic ways during audits:

  1. The Drag-n-Drop List:
  2. The Swipe-to-Delete:
    • Offer up a checkbox and delete button.
  3. The Canvas Drawing Tool:
    • This is difficult and relies on implementing a grid system for navigation. I detail this more in 2.5.1 Pointer Gestures.

Conclusion

2.5.7 is a reminder that convenience shouldn’t come at the cost of access. Drag-and-drop can be a great feature, but it should never be the only way to accomplish a task.

Comments closed
A11y 101: 2.5.4 Motion Actuationclose up of dog shaking water

A11y 101: 2.5.4 Motion Actuation

Published on March 23, 2026

Imagine you’re holding your phone, walking down the street, and you accidentally bump it against your leg. Suddenly, your app thinks you’ve shaken it into submission and deletes your entire shopping cart. Or maybe you’re trying to scroll, but the device interprets your hand tremor as a “shake to undo” command.

This isn’t just a quirky feature gone wrong; it’s a potential accessibility nightmare. Enter WCAG 2.5.4: Motion Actuation.

Continue readingA11y 101: 2.5.4 Motion Actuation
Comments closed
A11y 101: 2.5.3 Label in Nameclose up photo of a plastic bottle

A11y 101: 2.5.3 Label in Name

Published on March 16, 2026

We all navigate the internet and computers in different ways. Some use screen readers, others keyboard, and some people by voice. Success Criterion 2.5.3 was created to support these diverse methods. While it helps all users, it was created to address using voice control because typing is a struggle for the user. On the screen is a button that clearly says “Submit Order.” You speak the command: “Click Submit Order.”

Nothing happens.Or worse, it clicks the wrong thing.

Continue readingA11y 101: 2.5.3 Label in Name
Comments closed
A11y 101: 2.5.2 Pointer Cancellationan animation of pointing finger on a black background

A11y 101: 2.5.2 Pointer Cancellation

Published on March 2, 2026

Last week I wrote about gestures and pointers. This week we look at the next criteria, Pointer Cancellation. I mentioned that we wanted events to fire on the “Up” or “release” action. And that’s what this criteria is all about. We need to make sure that if a user creates a down event on a control, we need to allow them to cancel. Let’s look at the methods used.

Continue readingA11y 101: 2.5.2 Pointer Cancellation
Comments closed
A11y 101: 2.5.1 Pointer Gesturesbrown dog sitting on grass

A11y 101: 2.5.1 Pointer Gestures

Published on February 23, 2026

If you’ve been following my work or this blog for a while, you’ll know I’m always referencing that authors need to support both mouse users as well as keyboard users. What I haven’t mentioned much of is touch. Touch devices have given us a number of different modalities to interact with applications and the web. The problem arises when users don’t have the ability to touch the screen, or only have a single pointer when multiple are needed. Or perhaps they can’t perform the gesture. This is the point of this success criteria, providing an alternative for those users. Let’s check out how we do this.

Continue readingA11y 101: 2.5.1 Pointer Gestures
Comments closed
A11y 101: 2.4.11 Focus Not Obscured (Minimum)man sitting on a wheelchair
A11y 101: 2.4.7 Focus Visibleround mirror

A11y 101: 2.4.7 Focus Visible

Published on November 17, 2025

Disabilities come in all sorts. So do users. Some users can manipulate a mouse. Some rely on keyboard alone. Others have assistive technology. When you use a mouse, where your mouse is located is visible. This lets the sighted mouse user know what they are clicking on and where the focus is. Keyboard only users need something else. Let’s get into the details of what is needed.

Continue readingA11y 101: 2.4.7 Focus Visible
Comments closed
A11y 101: 2.4.6 Headings and Labelsvinyl music records with labels
Quick Tip: Use More Than Tab in Screen Readersblue laptop computer

Quick Tip: Use More Than Tab in Screen Readers

Published on November 3, 2025

It’s been a busy week in my house, so I’m going to keep this quick. One of the issues I often see flagged by other accessibility testers is that something doesn’t work with keyboard navigation. The vast majority of times I revisit these, it turns out the tester doesn’t fully understand how screen readers work. I want to highlight a few items for folks.

Modes

Screen readers typically have 3 main modes. The virtual browser, forms, and application.

Virtual Browser

The virtual browser is when the screen reader technology is intercepting the keyboard input and uses that to execute a function in the browser for you. When we press tab we jump to the next active item. Pressing the down arrow will read the next line, chunk, or set number of characters in a paragraph. Here’s a short list of common commands:

  • H: moves through the headings on the page
  • T: moves through the tables on the page
  • Control+Alt+Arrow: Move from one table cell to the next in the direction of the arrow
  • L: moves through the lists

Forms

When a user encounters a form element, the screen reader should automatically shift to the forms mode. There usually is ab audible sound to indicate this. This mode moves the screen reader out of the way to interact directly with the page via the keyboard. This limits how to navigate to using only the Tab and Shift keys to move among the active elements in the form.

Application

In this mode you need to have the role=”application” and then the screen reader again gets out of the way of the keyboard. However, even if you use active controls navigating between them is completely up to the author. They will work with Space & Enter to activate, but the author really needs to define the navigation scheme and controls to use the tool.

Don’t flag an issue for not being keyboard accessible with a screen reader on unless you can identify it is an application or is also not accessible without the screen reader.

There’s way more to this, but the great folks over at Tetralogical have a great screen reader misconceptions article and a full break down of commands.

Comments closed
A11y 101: 2.4.5 Multiple Waysclosed yellow elevator door

A11y 101: 2.4.5 Multiple Ways

Published on October 27, 2025

In the physical world we understand that not everyone can climb 20 flights of stairs, so under the ADA we created rules to overcome these situations. Buildings now have commitments they need to make during construction to include ramps and elevators to access areas that someone might not be able to climb stairs. This is an example of multiple ways. Let’s review how that translates to digital spaces.

Continue readingA11y 101: 2.4.5 Multiple Ways
Comments closed