a11y-forms

Form Accessibility

Skill type: Reference. This is teaching/pattern content — it explains label association, error announcement, fieldset/legend grouping, and validation patterns. It is not a scanner. For static review of existing forms, use /a11y-review. For runtime verification of error announcements and validation behavior, set up real axe via the a11y-testing skill and pair with manual screen reader testing.

Forms are the most interaction-critical UI element — and the most commonly broken for assistive technology users. Missing labels, inaccessible errors, and placeholder-as-label are among the top WCAG failures on the web.

---

The Non-Negotiable Rules

1. Every input must have a visible, programmatically associated label. No exceptions.
2. Never use placeholder as a label. Placeholder disappears on input, fails contrast, and is not reliably announced by screen readers.
3. Errors must be text, linked to the input, and not rely on color alone.
4. Required fields must be indicated programmatically (required or aria-required="true").

---

Label Association

Method 1: Explicit Association (Preferred)

<label for="email">Email Address</label>
<input type="email" id="email" name="email" autocomplete="email">

In React (htmlFor instead of for):

<label htmlFor="email">Email Address</label>
<input type="email" id="email" name="email" autoComplete="email" />

Method 2: Wrapping Label

<label>
  Email Address
  <input type="email" name="email">
</label>

Works well for radio/checkbox where the label and input are adjacent.

Method 3: aria-label (No Visible Label)

Use only when a visible label is genuinely not possible (e.g., search bar with a button):

<form role="search">
  <input type="search" aria-label="Search products" name="q">
  <button type="submit">
    <svg aria-hidden="true">...</svg>
    <span class="sr-only">Search</span>
  </button>
</form>

Method 4: aria-labelledby (From Existing Text)