Accessible Forms

Designing form inputs with clear labels, error messages, and keyboard support for all users.

stellae.design

Accessibility

Accessible forms ensure that all users can perceive, understand, complete, and submit form inputs regardless of ability. Forms are among the most critical and error-prone UI patterns for accessibility. WCAG 2.1 SC 1.3.1 (Info and Relationships, Level A) requires that labels and instructions are programmatically associated; SC 3.3.1 (Error Identification, Level A) requires errors to be identified in text; SC 3.3.2 (Labels or Instructions, Level A) requires labels for user input; SC 3.3.3 (Error Suggestion, Level AA) requires correction suggestions; and SC 4.1.2 (Name, Role, Value, Level A) requires all inputs to have accessible names. Forms touch nearly every WCAG principle and are where accessibility failures most directly prevent task completion.

Why It Matters

Forms are the primary mechanism through which users provide information, complete transactions, and accomplish goals on the web — from signing up for an account to filing taxes, booking medical appointments, and applying for jobs. When forms are inaccessible, the consequences extend far beyond inconvenience: people with disabilities are locked out of essential services, legal obligations under ADA, Section 508, and the European Accessibility Act go unmet, and organizations lose customers who simply cannot complete the conversion funnel. Because forms involve complex interactions — focus management, validation feedback, error recovery, and multi-step flows — they concentrate more accessibility challenges per square centimeter of interface than almost any other pattern.

Real-World Examples

UK Government Digital Service form patterns

The GDS design system provides form components where every input has a visible label, helper text is linked via aria-describedby, error messages appear inline above the offending field in red with a left border and prefixed with "Error:", and a summary of all errors appears at the top of the page as a linked list that jumps focus to each problematic field. The system uses native HTML validation attributes enhanced with JavaScript that provides consistent cross-browser behavior while maintaining the accessibility of native form elements. This pattern has been validated through extensive testing with real users of assistive technology across multiple government services handling millions of transactions.

Adobe's React Aria form components

Adobe's React Aria library provides unstyled, accessible form primitives — TextField, Select, Checkbox, RadioGroup, DatePicker — that handle label association, error messaging, description linking, required field announcement, and keyboard interaction out of the box while allowing complete visual customization. Each component manages its own aria-describedby relationships, announces validation errors to screen readers automatically, and supports both native validation and custom validation with proper aria-invalid state management. This approach demonstrates how component libraries can make accessible forms the path of least resistance by encoding accessibility requirements into reusable primitives.

Counter-example

Registration form using only placeholder text as labels

A SaaS onboarding form uses placeholder text as the only indication of what each field expects — "Enter your email," "Create a password," "Company name" — with no visible labels, no associated `<label>` elements, and no aria-label attributes. As soon as users begin typing, the placeholder vanishes and they cannot remember whether the current field expects a username or an email address, while screen reader users hear only "edit text, blank" for every field. The form also validates on submit with a single toast notification at the top of the page that says "Please fix the errors below" without identifying which fields have errors or providing any programmatic link to them.

Role-Specific Guidance

Common Mistakes

• The most fundamental and widespread form accessibility failure is omitting the programmatic association between labels and inputs — either by not using `<label>` elements at all, by using `<label>` without a `for` attribute, or by relying on placeholder text as the sole label, all of which leave screen reader users unable to identify what information a field requires. Another critical mistake is implementing validation that only communicates errors through visual changes like red borders without providing programmatic error information through `aria-invalid` and `aria-describedby`, making it impossible for non-sighted users to identify and fix problems. Teams also frequently create custom select dropdowns, date pickers, and toggle switches that look polished but break keyboard navigation, lack ARIA roles and states, and fail to communicate their current value to screen readers.