Lesson 5 of 30

Forms Accessibility: Labels, Errors, and Instructions

Q: You're implementing client-side validation for a signup form. When a field fails validation, red border styling and a small error message appear below it, purely via CSS and DOM text. Walk through what's missing for a screen reader user, and how you'd fix it end to end.

A strong answer covers: Identifies that the visual-only error is entirely invisible to a screen reader user — no announcement occurs on focus, blur, or submit; Names the specific fix: aria-invalid="true" set on the field when it fails validation, and aria-describedby pointing the field at the id of the error message element; Explains why timing matters — if the error appears while focus already sits in the field (e.g. on blur or failed submit), a live region or role="alert" on the error text is needed so it's announced proactively rather than only being read when the field is next focused; Confirms the fields also need a real label (for/id association), since none of the ARIA error wiring matters if the field has no accessible name to begin with.

A red border and small red text under a field is a purely visual error signal — invisible to a screen reader unless it's also wired up programmatically. Forms are where accessibility bugs compound fastest, and where the fix pattern is fully specified.

13 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

A form field uses only placeholder text ("Full name") instead of a `<label>`. Why is this considered a real accessibility bug rather than a minor style choice?

It disappears once typing starts and isn't reliably announced as the field's name, unlike a real programmatically-associated labelIt isn't a bug — placeholder text and label text are functionally interchangeable for both sighted and screen reader usersIt's a bug only because placeholder text is styled in a lighter gray color that fails contrast requirements

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Forms Accessibility: Labels, Errors, and Instructions

What interviewers actually ask about this, and what a strong answer has to cover.

You're implementing client-side validation for a signup form. When a field fails validation, red border styling and a small error message appear below it, purely via CSS and DOM text. Walk through what's missing for a screen reader user, and how you'd fix it end to end.

A strong answer covers

Identifies that the visual-only error is entirely invisible to a screen reader user — no announcement occurs on focus, blur, or submit
Names the specific fix: aria-invalid="true" set on the field when it fails validation, and aria-describedby pointing the field at the id of the error message element
Explains why timing matters — if the error appears while focus already sits in the field (e.g. on blur or failed submit), a live region or role="alert" on the error text is needed so it's announced proactively rather than only being read when the field is next focused
Confirms the fields also need a real label (for/id association), since none of the ARIA error wiring matters if the field has no accessible name to begin with

Likely follow-ups

The aria-invalid and aria-describedby attributes are added once in the initial markup, before any validation has run. Why is that likely still broken?

The plain-language idea

An accessible form field needs three things working together, and each is a real, specific mechanism, not a general good-practice gesture:

An explicit <label for="...">, not just visual adjacency. A label sitting next to an input in the layout means nothing to assistive technology unless it's programmatically tied to that input via for/id (or by wrapping the input inside the <label>). A placeholder is not a substitute: placeholder text disappears the instant the user types, and isn't announced with the same reliability as a real label — it should describe an example value, never stand in for the field's name.
<fieldset> and <legend> for grouped fields. A set of radio buttons answering one question ("Preferred contact method") needs a <fieldset> wrapping the group and a <legend> naming the question, so a screen reader announces the group's purpose once before reading the individual options — without it, a user tabbing through radio buttons hears "Email, Phone, Text" with no idea what question they're answering.
A programmatically connected error state, not just a visual one. aria-invalid="true" on the field marks it as currently failing validation, and aria-describedby pointing at the actual error message text makes that message get announced when the field receives focus — the same field-level pattern aria-describedby provides for hint text, just wired to error content this time.

See it in a real thing: a validation error, done right

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
/>
<p id="email-error" role="alert">
  Enter a valid email address.
</p>

Three things happen together here: the label is really connected via for/id, aria-invalid="true" tells assistive technology this specific field is currently in an error state, and aria-describedby="email-error" links the field to the actual error text so it's announced right after the field's name when focus lands there — not just visible somewhere on the page. role="alert" on the error paragraph turns it into a live region, so if the error appears after the field already has focus (e.g. on blur, or after a failed submit while focus stays put), it's announced proactively instead of requiring the user to go looking for it. Live regions get their own deeper treatment in a later lesson — the pattern here is the specific instance that matters most: form validation.

What people usually miss

Watch out

Visual and programmatic error signals are two separate requirements, and both have to exist. Red text alone satisfies sighted users; aria-invalid and aria-describedby alone (with no visual change) fail low-vision users who aren't using a screen reader. The accessible pattern requires both together, not either one.
A placeholder is not a label, ever — it's a hint about format or an example value at most. Once a user starts typing, the placeholder is gone, and there's nothing left identifying the field for anyone relying on that text (visually or via assistive technology) to know what they're filling in.
<fieldset>/<legend> matters most exactly when it's easiest to skip — a short, seemingly self-explanatory group of radio buttons or checkboxes. The individual option labels ("Yes," "No") mean nothing without the question they're answering, and that question is exactly what gets lost without a real <legend>.
aria-describedby for an error only helps if it fires when the user needs it, not just when the page loads. Adding the attribute once at initial render, before any error exists, and never updating aria-invalid/aria-describedby when a real error appears is a common half-implementation that looks correct in the initial markup and fails at the moment it actually matters.

Why this matters in interviews

"Build a form field's error state so a screen reader user actually knows validation failed" is a standard practical exercise, and the strong answer names the full connected pattern — real label, aria-invalid, aria-describedby pointing at the message, and a live region or role="alert" so it's announced proactively — rather than stopping at "add ARIA to the error text."