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 closedThis post discusses eating disorders, mental health, adverse medication reactions, and hospitalization. If you’re struggling, please reach out to a healthcare professional. You deserve support.
Three months ago, I published “When Algorithms Forget You’re Human.” I wrote about my wife—recovering from an eating disorder, doing well (over a decade with no lapse), dealing with weight gain from disability changes—and how social media kept serving her GLP-1 ads. Skin removal surgery. Weight loss programs. Sono Bello showed up eleven times after she blocked them.
I wrote about how algorithms don’t respect choices. How Amazon Prime offers no way to mark content as problematic. How AI systems act as yes men. How platforms treat vulnerability as revenue opportunity.
Today is three months to the day since that post.
My wife is in a hospital bed.
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 closedYou’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 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 closedMy last post was on 3.1.1 Language of the page. We talked about telling the screen reader the main language of the page. It’s like setting the thermostat for the whole house.
But what if you have a guest room where the temperature needs to be different? Or a kitchen where the oven is on?
That’s 3.1.2: Language of Parts.
Comments closed
