Imagine walking into a restaurant in a foreign country. The menu is beautiful; elegant typography, gorgeous layout, mouth-watering descriptions. There’s just one problem: you don’t speak the language. You point at something random and hope you didn’t just order the sheep’s stomach stew.
Comments closedHere’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 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 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 closedHeadings and labels need to describe the content they are identifying in the content. This means when you have a H1 is should describe the page as a whole. Labels need to describe the data they are collecting. Seems simple. And usually it is. Let’s look at some examples of when it isn’t as clear.
Comments closedIn 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.
Comments closedIf you are anything like me, you don’t want your data sold to third parties. You probably run ad blockers. Maybe a VPN. Some governments are trying to help by requiring the site to declare what cookies are used and providing the user to opt out. But the current method of displaying this information tends to have some serious accessibility issues. I have another way of thinking about them I’d like to propose.
Leave a Comment
