Form hints: connect help + errors with aria-describedby

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

What goes wrong

Many UIs show helpful text under a field (requirements, examples) and then show an error message when validation fails. Visually, it looks fine — but if the input isn’t connected to that text, assistive tech can miss it or present it inconsistently.

• Hints aren’t read when the field receives focus.
• Error messages aren’t associated with the field that caused them.
• People who rely on spoken output can end up in a frustrating loop: “Something’s wrong” with no clue what to fix.

Minimal pattern

Use a real label for the field’s name, then use aria-describedby for extra description (help text, requirements, and (optionally) the current error message).

<label for="pw">Password</label>
<div id="pw-help">Use 8+ characters. Add a number.</div>
<div id="pw-err" hidden>Use at least 8 characters.</div>

<input id="pw" type="password"
  aria-describedby="pw-help"
  autocomplete="new-password" />

// show error text
pwErr.hidden = false;

// make it programmatically associated
pw.setAttribute('aria-invalid', 'true');
pw.setAttribute('aria-describedby', 'pw-help pw-err');

Checklist / gotchas

• Keep the label separate. aria-describedby is not a label. Use <label for> (or aria-label/aria-labelledby if you must).
• IDs must exist. Every token in aria-describedby should point to an element that’s in the DOM.
• Order matters. If you include multiple IDs, list them in the order you want them read (help first, then error).
• Don’t overload it. Keep descriptions short and actionable. If you need a paragraph, consider a “Learn more” link near the field instead.
• Don’t hide the only guidance in hover-only tooltips. If a hint matters, it should be visible or at least reachable on focus.