UI Coach guide
Accessible Form Design
Accessible forms: labels, instructions, errors, and keyboard access that work with assistive technology.
By UI Coach Editorial ·
An inaccessible form can look finished in a visual mock and still be unusable. The person using a screen reader, keyboard, or voice input needs a name for every field, a known purpose where relevant, and errors that are announced rather than only painted red.
Every field needs a name
Programmatic labels must be associated with controls. Placeholder-only fields fail this. Clickable text that is not tied to the input fails this. W3C tutorials on form labels exist because this is a frequent production bug, not an edge case.
Group related controls
Radio sets and checkbox groups need a group name, not only individual options. Fieldsets and legends, or their design-system equivalents, make the question clear.
Errors must be available to assistive tech
Moving focus to the first error, using aria-describedby or equivalent for the message, and not relying on color alone are baseline practices. A summary of errors at the top helps when the form is long.
Do not block paste or managers
Password managers and autocomplete are accessibility and usability features. Splitting inputs and disabling paste causes real-world failures.
Practice this on UI Coach
Take a form-heavy challenge and annotate label, error, and focus for each field. Then use accessibility tools from Resources to check contrast and hit areas. Jobs that mention inclusive design are describing this work.
Sources
- W3C WAI tutorials on form labels
- WCAG understanding documents on input purpose