You’re filling out your taxes. Your cursor lands in the first field. You start typing. And halfway through entering your email address—whoosh!—the form submits automatically.
Now you’re looking at an error page because you didn’t finish. Or worse, you submitted incomplete data and lost what you had typed. Your screen reader says something confusing. You have to start over.
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 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 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 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 CommentI’ve been encountering a pattern lately of developers trying to do things right when it comes to live regions, but not understanding how they essentially work. This tip is to provide a super high level on how they function.
Leave a CommentLinks are what make the internet the world wide web. The original idea was that the internet is a set of digital documents. The link allows you to move between them. To make them as effective as they can be, we want to make them clear in what they do. Often though, the simple link doesn’t provide a clear purpose. Let’s look at what it takes to pass 2.4.4 Link Purpose (in Context).
Comments closedThe internet today far exceeds what we initially thought it could be. We’ve advanced so far that we can replicate desktop applications running in the browser. Cloud-based software is everywhere. We’ve crafted frameworks to speed up development and solve the hard parts of server-client communication.
But the same problem keeps happening. We keep rebuilding interactive components using custom coding. And we forget all the things we need to do to make them accessible.
Today I’m looking at a why we should be using more native HTML controls and fewer custom ones. I’ll show you what is included if you use a native control.
Comments closedYou’ve most likely heard the term “skip link.” The standard take on the skip link is we include a visually-hidden link at the top of the page. When it receives focus, it becomes visible and when activated jumps you to the main content. While this is the primary use and function of this guideline, I’ve found it applies to other areas. Let’s look at the different reasons and methods.
1 Comment
