You 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 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 closed
