A11y 101 – 3.3.3 Error Suggestion

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.

The Requirement

Let’s parse that carefully:

• Automatically detected — validation happens on submit, not later
• Suggestions for correction — not just “failed,” but “here’s what to do”
• If applicable — sometimes there’s no suggestion to give, like when a username is already taken by someone else

But here’s the thing: most forms have something to suggest. The question is whether you’re willing to communicate it.

The Difference Between 3.3.1, 3.3.2, and 3.3.3

I know you’re tracking these by now, so let me be precise about where each one fits:

Criterion	Timing	What It Does
3.3.2 Labels or Instructions	Before	Set expectations upfront
3.3.1 Error Identification	After	Tell them where they erred
3.3.3 Error Suggestion	After	Tell them how to fix it

They’re a chain. Miss any link, and the user falls through.

Success Criterion 3.3.3 is the sprint to the finish. It’s the difference between pointing at a wall and handing them a ladder.

The “Invalid” Lie

Here’s what I hate about “Invalid”:

• It’s passive. Nothing happened. Something was wrong.
• It’s vague. Which field? Which rule?
• It’s unhelpful. It solves nothing.

Bad:

Error: Invalid email

Good:

Error: Your email is missing a domain. Try "name@example.com"

One tells them something failed. The other tells them how to succeed. The first is a dead end. The second is a path forward.

Code Patterns: From Dead End to Direction

Let me show you the difference in implementation. First, the lazy way:

<!-- BAD: No suggestion provided --> 
<form id="lazyForm"> <label for="email-lazy">Email</label> <input type="email" id="email-lazy"> <span id="email-error-lazy" role="alert"></span> <button type="submit">Submit</button> </form> <script> const lazyForm = document.getElementById('lazyForm'); lazyForm.addEventListener('submit', function(e) { e.preventDefault(); const email = document.getElementById('email-lazy'); const err = document.getElementById('email-error-lazy'); if (!email.value.includes('@')) { // Generic failure message err.textContent = "Invalid"; // No guidance on how to fix } }); </script>

Now, the version that respects the user:

<!-- GOOD: Specific suggestion provided --> 
<form id="smartForm"> <label for="email-smart">Email</label> <input type="email" id="email-smart"> <small id="email-hint" style="display:none;">Try format: name@example.com</small> <span id="email-error-smart" role="alert"></span> <button type="submit">Submit</button> </form> <script> const smartForm = document.getElementById('smartForm'); smartForm.addEventListener('submit', function(e) { e.preventDefault(); const email = document.getElementById('email-smart'); const err = document.getElementById('email-error-smart'); const hint = document.getElementById('email-hint'); if (!email.value.includes('@')) { // Specific failure + actionable suggestion err.textContent = "Your email is missing a domain."; hint.style.display = 'inline'; // Link them programmatically email.setAttribute('aria-describedby', 'email-error-smart email-hint'); email.setAttribute('aria-invalid', 'true'); } }); </script>

See the difference? One stops at the problem. The other offers the solution.

Real-World Scenarios Where Suggestions Matter

Some errors are obvious. “First Name is required.” The suggestion is implicit: fill it in.

Others need explicit guidance. Here are common cases where suggestions make the difference between success and abandonment:

• Format Requirements: “Your phone number needs 10 digits. Format: 555-555-5555”
• Character Limits: “Username must be under 20 characters. You’re currently at 28.”
• Taken Values: “This username is already in use. Try adding your initials: johnD123”
• Security Constraints: “Password needs one uppercase letter, one number, and one special character”
• Date Conflicts: “Check-in date can’t be after check-out date. Adjust accordingly”

In each case, the user knows what broke and how to repair it.

When There Is No Suggestion

There are times when you genuinely can’t offer a suggestion:

• The email domain is valid, but the account doesn’t exist
• The payment card is declined for reasons you can’t disclose
• The API endpoint is unreachable due to a server issue

In those cases, be honest. Don’t pretend you know the answer.

• “That email wasn’t found. Please verify or create a new account.”
• “Payment couldn’t process. Check with your bank or try a different card.”
• “Something went wrong on our end. Please try again in a moment.”

Honesty is better than a fake suggestion. At least the user knows where they stand.

Think of the User

When we withhold error suggestions, we’re making a choice. We’re deciding that explaining the fix is too much work. That the user can figure it out on their own. That we’re absolved of responsibility once the error fires.

But accessibility isn’t about absolution. It’s about partnership. We build the system. They use it. When they stumble, we help them up.

For users with cognitive disabilities, this partnership matters even more. Ambiguity drains working memory. Unclear directions multiply stress. Every extra guess costs energy they might not have.

A clear suggestion isn’t a luxury. It’s a bridge.

Wrapping Up

“Invalid” is never enough. It’s a dead end. A door slammed shut.

Error suggestions open doors. They show users the way forward. They turn frustration into progress.

Don’t just say something’s wrong. Say what to do about it.

Your users will thank you. And more importantly, they’ll actually be able to finish the thing you asked them to do.

Want to discuss this? find me on LinkedIn and BlueSky.