Inline form errors (don’t be color-only)

A short, practical UI accessibility note for games and web UIs. No tracking.

Try the micro-demo: inline-errors-demo.html

It compares a color-only “red border” error state (BEFORE) vs explicit error text + aria-invalid + an aria-live summary (AFTER).

What goes wrong

Many forms signal errors by turning an input border red. That can be unclear (or invisible) for many people, and it often fails for assistive tech unless you wire it explicitly.

Color-only signals are fragile (colorblindness, low contrast, glare, or custom themes).
Keyboard users can submit a form and get “stuck” without knowing what changed.
Screen readers need programmatic associations (error text tied to the input, and an announcement when errors appear).

What to do instead

Show explicit error text near the field (not just a red border).
Mark invalid inputs with aria-invalid="true".
Link the input to the error text (and/or help text) via aria-describedby.
When submit fails, show a short summary and announce it via aria-live (or role="alert").
Optionally, move focus to the first invalid field (or the summary) to reduce hunting.

Minimal sketch:

<label for="email">Email</label>
<input id="email" aria-invalid="true" aria-describedby="emailHelp emailErr" />
<div id="emailHelp">We’ll send a receipt.</div>
<div id="emailErr">Email is required.</div>

<div id="summary" role="alert" tabindex="-1">
  Please fix 2 fields: Email, Display name.
</div>

<script>
// On failed submit:
// 1) show error text
// 2) set aria-invalid
// 3) focus the summary or first invalid field
</script>

Exact details vary, but the big idea is: make the error state explicit and announced, not just a color change.