Validation feedback

Validate on the client to help the user, and show each error next to the field it belongs to, tied with aria-describedby. Show errors after the user has touched the field, not while they are still typing their first character.

What a session covers

The tutor works through these with you, in conversation and code. A session ends when you have shown them, not when a video does.

Explain when an error should appear next to a field
Show each error beside its field and link them with aria-describedby
Spot client-only validation and explain why the server must check again

In practice

A few lines that show Validation feedback doing its job.

TSX

const error = touched && !email.includes("@") ? "Enter an email address" : null;

<input
  id="email"
  value={email}
  onChange={(e) => setEmail(e.target.value)}
  onBlur={() => setTouched(true)}
  aria-invalid={error ? true : undefined}
  aria-describedby={error ? "email-error" : undefined}
/>
{error && <p id="email-error" role="alert">{error}</p>}

The common mistake

Watch for

Trusting client validation as the only check. Anyone can bypass it; the server must validate again, and the form must show the server's errors too.

What to know first

Your roadmap puts these before Validation feedback, unless you already know them.

How it stays learned

Once a session shows you understand Validation feedback, it comes back for review. Each review takes a minute and tells the memory model how well you still know it.

Day 3First recall, while it is fresh
Day 7Second, a week on
Day 18Last, when it has settled

Previous in the module← Form submission