How to test forms for accessibility

If you only had time to accessibility-test one part of an app, test the forms. They're where users actually do things — sign up, pay, book, submit — and they're where accessibility fails hardest, because forms combine labels, validation, focus management, dynamic errors, and required-field logic, each with its own failure mode. A form that's beautiful with a mouse can be unusable with a keyboard or a screen reader. This is the form-specific drill-down from the accessibility smoke test, building on the keyboard and screen reader passes.

1. Every field has a real, associated label

Not placeholder text — a label. Click the visible label text: does it focus the field? If yes, they're associated and a screen reader will announce it. If clicking the label does nothing, it's not wired up, and the field announces only "edit text." Placeholder-as-label is the classic anti-pattern: it vanishes when you start typing, fails contrast, and isn't reliably announced.

2. Required and optional are communicated beyond colour

A red asterisk alone isn't enough — colourblind users and screen-reader users miss it. Required state should be programmatically present (announced as "required") and indicated in a non-colour way. Test by listening (does the reader say "required"?) and by imagining the form in greyscale (can you still tell which fields are mandatory?).

3. Errors are the big one

Validation is where forms most often fail accessibility. Submit the form with mistakes and check:

• Are errors announced? A sighted user sees red text appear; a screen-reader user needs it spoken (via a live region or by moving focus). Silent errors mean the user has no idea why submission failed.
• Is the error tied to its field? "This field is required" floating at the top, unlinked, leaves the user hunting. The error should be associated with the specific input.
• Does focus move to the problem? On a failed submit, focus should land on the first error (or a summary), not stay on the submit button or jump to the top with no indication.
• Is the message useful? "Invalid input" tells nobody anything; "Email must include an @" is actionable. (This overlaps with plain bug-report clarity — vague is vague everywhere.)

4. Keyboard operability end to end

Complete the entire form with the keyboard only — including the parts that aren't plain text inputs:

• Custom dropdowns, date pickers, comboboxes, and multi-selects: reachable AND operable with arrows/Enter/Space?
• Radio groups and checkboxes: navigable and toggleable?
• The submit button: reachable, and does the form submit on Enter from a field where expected?

Custom widgets are where keyboard support silently dies. A native <select> works for free; a fancy custom one often doesn't.

5. Focus and grouping

• Related fields (an address block, a set of radios) should be grouped so their shared label/legend is announced, not just the individual fields.
• After submission — success or error — focus should go somewhere sensible (the confirmation, the first error), not vanish to the top of the page leaving the user lost.

Where this fits

Forms are the highest-leverage accessibility target, sitting at the intersection of the keyboard pass, the screen-reader pass, and the full smoke test. The accessibility checklist has the structured version and the glossary defines label association, live regions, and fieldset/legend.

Accessible-form pass

• Every field has a real label that focuses the input when clicked (not placeholder-as-label)
• Required state is announced and indicated beyond colour alone
• Errors are announced (live region / focus move), tied to their field, and actually useful
• Focus moves to the first error on a failed submit
• The whole form is operable by keyboard — including custom dropdowns, date pickers, radios
• Related fields are grouped; focus lands somewhere sensible after submit