Script preview
There I was, sitting in the car on the way to the airport, trying to check in for my flight. The form was long, I was on my phone, and no matter what I did, it just wouldn’t submit. I kept prodding the button, wondering what was wrong. Turns out, there was an error about halfway up the form, but there was no way to know that without hunting for it. So. Frustrating.
Eventually, I figured it out—and then had to explain it to my coworker, who ran into the exact same issue. It made me think: why wasn’t this form designed to help me figure out what went wrong?
Welcome to What in the World is WCAG? 3.3 Input Assistance.
Labels or Instructions
Let’s say you’re filling out a field labeled “Name.” Easy, right? But does it mean your full name, just your first name, or something else? Without clear labels or instructions, users are left guessing. And for those using screen readers, the lack of clarity can make navigating forms even more frustrating.
This criterion helps everyone by requiring that input fields have explicit labels or instructions, either visible near the field or accessible via assistive technology. Whether it’s “First Name (as it appears on your ID)” or “Enter your date of birth (in this format),” clear guidance ensures users know exactly what’s expected.
Error Identification
Have you ever submitted a form and nothing happened? No confirmation, no helpful hint, just… nothing? It’s frustrating, right? Now imagine you’re using a screen reader or navigating without a mouse—tracking down the problem becomes an even bigger challenge.
When a user makes a mistake on a form, the error must be clearly indicated and easy to find. This might mean highlighting the problematic field, adding an error message like “This field is required,” or providing an icon to signal where the issue is.
It’s about giving users the feedback they need to fix the problem quickly, instead of leaving them guessing.
Error Suggestion
Identifying errors is step one, but what happens next? Imagine picking out a new password and getting an error message that just says, “Invalid password.” That’s not exactly helpful, is it?
As an example, if your password is rejected, a more useful message might say, “Password must be at least 8 characters long and include a number.” Or if you forget to enter your email address, the form could say, “Please enter a valid email address in the format example@domain.com.” Clear suggestions like these take the guesswork out of fixing mistakes.
Error Prevention (Legal, Financial, Data) / Error Prevention (All) (Level AAA)
We’ve all been there—you’re about to submit a form for something important, like booking a flight, paying a bill, or signing a contract. The stakes are high, and the last thing you want is to hit submit and realize you made a mistake you can’t undo. That’s where Error Prevention comes in.
For legal, financial, or data-related actions, Error Prevention (Level AA) requires safeguards to help users avoid costly or irreversible mistakes. This could mean offering a confirmation page to review details before submitting, or having an “undo” option so users can fix errors after submission.
At Level AAA, this success criterion expands beyond high-stakes actions to include all user inputs, giving users the chance to confirm or correct their input before any major change takes effect. Think of a shopping cart that asks, “Are you happy to complete this purchase?” before completing the order. It’s a simple step that prevents accidental clicks from turning into unintentional purchases.
So give users peace of mind, reduce anxiety, and make it easy to fix mistakes before they become problems.
Redundant Entry
But my billing address is the same as my shipping address! Why do I have to type this in twice, why couldn’t you just put that little tickbox in that says ‘billing address is same as shipping address’ and save me the hassle?
Asking users to type in the same information more than once isn’t allowed, nor should it be. There is an exception for confirming email addresses and passwords, ‘cuz we all know that doing it twice is for our own safety.
Accessible Authentication (Minimum)/Accessible Authentication (Enhanced)
The other night, I ordered pizza. I thought I’d be logging into the site, but after it asked for my email, it didn’t ask for my password. Instead, it told me to check my email. They sent what’s known as a magic link—clicking it logged me in with all my saved details ready to go. No password to remember, just pizza on the way.
That’s the beauty of accessible authentication. At the Minimum level, this success criterion ensures that users don’t have to rely on memory or tricky cognitive tasks, like solving math equations, to log in. Options like magic links or password managers are great for everyone.
But there are still challenges: multi-factor authentication (MFA), CAPTCHA, and transcription can still trip people up. On the plus side, devices like smartphones are getting better at making these accessible. My phone recognizes codes from emails and text messages automatically, making the process smoother than ever. Now if only my desktop would catch up…
At the Enhanced level, things get even better. It removes some of the more tedious and inaccessible methods, like transcription tasks and CAPTCHAs entirely. Instead, it prioritizes user-friendly options like biometric authentication—fingerprints, face recognition, or voice authentication. These methods don’t just eliminate barriers; they also provide independence and security for users who might otherwise struggle with traditional login methods.
If you want a deeper dive on this one and to learn about Cognitive Function Tests, check out our WCAG 2.2 video on accessible authentication.
Input Assistance: Because mistakes happen.