Here’s a scenario I see all the time. A designer hands me a mockup with these elegant, tiny icons in a row; maybe a toolbar with edit, delete, and share buttons, each one maybe 16 pixels square. Looks clean. Minimal. Modern.
Then I put my thumb on it. And I miss. Every. Single. Time.
Comments closedPicture 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.
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.
Dragging movements assume a level of motor control that not everyone has:
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.
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.
I’ve seen this fail in a few classic ways during audits:
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 closedImagine 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.
Comments closedThe <abbr> element stands for abbreviation. The idea behind this is you provide the abbreviation of the word or phrase, then use the title attribute to display the whole name or phrase.
<p>You need to pay your taxes to the <abbr title="Internal Revenue Service">IRS</abbr> for many years.</p>The problem with this is that the <abbr> is not an interactive element. You cannot tab to it. It will be read just like any other word in the sentence. If you mouse over the element, you see the title. But if you use keyboard there is no way to expose it.
Then there are screen readers. Most screen readers will not announce this title.
It’s better to fall back to the old newspaper styling where you say the whole phrase the first time followed by the abbreviation in parenthesis. From there forward, you can use the abbreviation.
Take a look at the testing Adrian Roselli has done on this.
Comments closedWe 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.
Comments closedThe specifications for dialogs and modals recommend placing focus on the first focusable item in the dialog. The vast majority of the time this is a close button. this means that a screen reader user will hear something similar to “Dialog, Shopping Cart, Close, button.”
As a user this is confusing. I just added something to my cart, or I just opened it to checkout. And now your site is telling me that while I’m in the cart I should close it.
I strongly recommend that this is not the best practice we should be following. We should be providing the user with information they need in a way that encourages them to explore. To accomplish this, I recommend placing the focus on the heading of the dialog. We do this by providing a proper ID and tabindex="-1". Now when the user opens the cart dialog they would hear something like “Dialog, Shopping Cart.” This tells me my focus has shifted due to my actions, where the focus went by identifying, and I’m not hit with the confusing close button.
This is my opinion, it differs from many, but it fills the gap between accessibility and user experience to create a better flow for everyone. But I’m not alone in this opinion.
Comments closedLast 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.
Comments closedIf 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.
Comments closedModern dynamic websites use layers of content on a page. We have tooltips, popups, dialogs, menus, navigation, and modals that bring more functionality by using these layers. But they can introduce a problem for keyboard-only users when focus can fall on content underneath. Let’s explore how this can resolved.
Comments closedDisabilities 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.
Comments closed
