Accessible forms

01Labels come first

Every field needs a visible label that is programmatically linked to it. In HTML, that means a <code>label</code> element whose <code>for</code> matches the input’s <code>id</code>. Clicking the label then focuses the field, and screen readers announce it.

Never use a placeholder as the only label. It disappears when typing, often has weak contrast and is easy to mistake for a filled value.

02Hints, required fields and autofill

• Hints such as format examples (“DD/MM/YYYY”) belong in visible text below the label, linked to the field with <code>aria-describedby</code>.
• Required fields should be marked in text, not by colour or an asterisk alone. Explain the marker at the top of the form. The <code>required</code> attribute exposes the state to assistive technology.
• Autocomplete: WCAG 1.3.5 Identify Input Purpose (AA) asks for the right <code>autocomplete</code> tokens on fields about the user, such as <code>name</code>, <code>email</code> and <code>tel</code>.

03Group related controls

Radio buttons and checkbox sets answer one shared question. Wrap them in a <code>fieldset</code> and name the question in a <code>legend</code>. Otherwise a screen reader user hears “Yes” or “Monthly” with no question attached.

04Errors that help

WCAG 3.3.1 Error Identification (A) requires that an error is identified and described in text. WCAG 3.3.3 Error Suggestion (AA) asks for a suggested fix when one is known.

1. Describe the problem and the fix: “Enter a date like 25/12/2026”, not “Invalid input”.
2. Show the message next to the field and add an icon or text, not colour alone.
3. After a failed submit, show an error summary at the top that lists each problem with a link to its field.
4. Move keyboard focus to that summary so screen reader users hear it immediately.

Layout affects accessibility as much as markup. Simple, predictable forms are easier for everyone, including people who use screen magnifiers or voice control.

• Place labels above fields. They stay visible at high zoom and on narrow screens.
• Use a single column for most forms, so the reading order is obvious.
• Match the input type to the data, such as <code>type="email"</code> or <code>type="tel"</code>, so mobile keyboards adapt.
• Ask only for what is needed. Every extra field is another chance for an error.

Do not clear the form after an error. Keep what the user typed so they only fix the problem field.

05Sources

• W3C WAI. Forms Tutorial. https://www.w3.org/WAI/tutorials/forms/
• W3C. Understanding SC 1.3.5 Identify Input Purpose. https://www.w3.org/WAI/WCAG22/Understanding/identify-input-purpose.html