You’re shopping online at your favorite store. You set up an account for future visits. You fill out your name, email, shipping address, billing info, card details. You save the info.
You start shopping and add some items to the cart. The checkout form asks for all that information again. Name, email, address, card. All of it. Fresh blanks.
You stare at the screen. “Didn’t you already know this?”
Comments closedImagine buying a car. You sign a contract. Then you discover the dealership changed the interest rate after you clicked “Accept.” Or you transfer money to a bank account. You confirm the transaction. Then you realize you sent it to the wrong person—and the funds are gone.
These aren’t typos. These aren’t forgotten passwords. These are consequential actions with legal, financial, or irreversible data implications.
And if your interface doesn’t protect users from making these mistakes, you’re not just violating WCAG—you’re exposing yourself to liability.
That’s the core of WCAG 3.3.4: Error Prevention. Unlike 3.3.3, which is about helping users fix field-level validation errors, 3.3.4 is about preventing catastrophic mistakes before they happen.
Comments closedYou submit a form. An error flashes: “Invalid.” That’s it.
Invalid what? Invalid how? Invalid because you used the wrong format, or invalid because the email is already taken, or invalid because the server had a seizure and forgot what an email even is?
For all the user knows, the system is lying. The form is broken. They’re blocked, with nowhere to go.
That’s where WCAG 3.3.3: Error Suggestion comes in. And its message is simple: tell people how to fix it.
Comments closedBefore I Can Fill It, I Need to Know What You’re Asking
There’s a form I encountered recently that had twelve fields. No labels. Just placeholder text inside each input that disappeared the moment you started typing. If you forgot what a field was asking for, you had to delete everything you’d entered just to see the hint again.
Twelve fields. Zero labels. Infinite frustration.
That’s not a design choice. That’s a barrier. And it’s exactly the kind of thing WCAG 3.3.2: Labels or Instructions exists to dismantle.
Comments closedWe’ve all been there. You fill out a form. You hit submit. Nothing happens. Maybe the border turns red. Maybe a little icon winks at you. Maybe your computer hums aggressively. But nobody tells you what went wrong.
You stare at the screen. “Did it fail? Did it work? Am I now married to a stranger?”
Silence is rude. Silence is inaccessible. And silence violates WCAG 3.3.1: Error Identification.
Comments closedWhy Labels Need to Match Across Pages
You’re at a party. Someone introduces themselves as “Michael.” You shake his hand, have a nice conversation, move on. Later that evening, you see him again across the room. You walk over and say, “Hey, Michael!” He looks at you blankly. “It’s Mike now.” Weird, but okay. A while later, you spot him by the snack table. “Mike!” you try again. He turns around. “Actually, it’s Mikey.”
You’d stop trying, right? You’d start avoiding this person. Not because you don’t like them, but because the rules keep changing and you can’t keep up.That’s what inconsistent identification feels like on a website.
Comments closedIf I had a podcast, I would tell you to close your eyes and imagine the following. But this is a blog post…
You’re walking down a hallway, hand out, ready to turn a doorknob. Your hand lands on the knob… and suddenly the door slides open before you touch it. Or worse, the room you thought you were entering is actually a closet full of vacuum cleaners. Disorienting, right? Jarring? A little bit scary?
That’s how a user feels when they tab through a webpage and a piece of content jumps, moves, or redirects them without asking for permission first.
Comments closedImagine 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 closed
