Form accessibility patterns that work

Forms are where most accessibility audits surface concrete defects. Buttons can be styled badly without blocking a user; a broken form blocks the task entirely. This guide covers twelve patterns we apply on every form audit and rebuild.

1. Every input has a programmatic label

Every <input>, <select> and <textarea> must have a programmatic label, either via <label for="..."> or aria-label. Placeholder text is not a label. The label must persist when the field is filled, otherwise screen readers lose context.

2. Required fields are marked twice

Mark required fields visually (asterisk, "required" text, or both) and programmatically with HTML5 required or aria-required="true". The asterisk alone is not enough.

3. Errors announce themselves

Inline error messages must be programmatically associated with the field via aria-describedby, and must be wrapped in a polite live region (aria-live="polite") so screen readers announce them when they appear. Bonus: set aria-invalid="true" on the field itself.

4. Validate at the right time

Validate on blur, not on every keystroke. Validating as the user types creates noise for screen readers and creates anxiety for everyone else. The exception is positive confirmation (a green tick on a passing field), which can appear as the user types.

5. Set the autocomplete attribute

Common values: name, email, tel, street-address, postal-code, cc-number, new-password, current-password. The full list is in the HTML specification. This is WCAG 1.3.5 (AA) and supports password managers, mobile keyboard suggestions and form autofill.

6. Match input type to expected data

type="email" brings up the email keyboard on mobile. type="tel" brings up the numeric keypad. inputmode="numeric" brings up numbers without the dialer-style layout (better for OTP codes, post codes, ABN entry).

7. Group related fields

Use <fieldset> with a <legend> to group related fields like address blocks, name parts (given name, family name) and date pickers. Screen readers announce the legend before each contained field, providing context.

8. Multi-step forms remember

If a user navigates back, their previously entered values must persist. WCAG 3.3.7 Redundant Entry (A) requires this for any process. Implementation: keep state in the URL, sessionStorage, or server-side session.

9. Allow paste into all fields

Disabling paste on password, credit card or one-time-code fields is a WCAG 3.3.8 (AA) failure. Users with cognitive disabilities, motor impairments, or anyone using a password manager rely on paste.

10. Respect default keyboard focus

Do not auto-focus the first input on every page load. It defeats focus order for users who navigated with a screen reader or keyboard. Auto-focus only when the form is the explicit purpose of the page (a search input on a search page, a login on a login page).

11. Submit buttons describe their action

"Submit", "Continue", "Next" are weak. "Continue to payment", "Save changes", "Confirm booking" are strong. Each button label should be understandable out of context, since assistive technology users often navigate by the buttons list.

12. Confirmation states are accessible

After submission, the success state must be announced to screen readers via a live region or a focus shift to the confirmation heading. A page change without focus management leaves screen reader users uncertain whether anything happened.