Accessible forms are web forms that every user can perceive, understand, operate and correct, regardless of whether they use a mouse, a keyboard, a screen reader, voice control or screen magnification. In web accessibility, forms are among the most critical components, because signups, checkouts, applications and logins all depend on them, and one unlabeled field or unannounced error can block a task completely.
The requirements come mainly from WCAG 2.2, whose success criteria on labels, input purpose, error identification and error suggestion apply directly to forms. Most of them are met by correct native HTML, with ARIA used only to fill genuine gaps.
How assistive technology reads a form
A screen reader does not see the visual layout. It reads the accessibility tree, where each control exposes a role, an accessible name, a state and a description. When a user tabs into a field, the screen reader announces something like “Email, edit text, required, invalid entry”, and every part of that sentence must come from the markup.
The table shows where each piece of announced information originates in well-built HTML.
| Announced property | Source in markup | Example |
|---|---|---|
| Accessible name | label element linked with for and id | Email address |
| Role | Native element type | Edit text, checkbox, combo box |
| Required state | required or aria-required attribute | Required |
| Invalid state | aria-invalid set after validation | Invalid entry |
| Description | aria-describedby pointing to hint or error | Use at least 12 characters |
| Group label | fieldset with legend | Delivery method |
Labels, instructions and grouping
Every input needs a visible, programmatically associated label. A placeholder is not a substitute for a label: it disappears on input, often fails contrast requirements and is inconsistently announced. Labels should sit close to their field, above it or to the left, so that users of screen magnification see both together.
Format instructions, such as a required date pattern or password rules, belong before or directly under the field and are connected through aria-describedby. Related controls, especially radio buttons and checkbox sets, are wrapped in a fieldset with a legend so the question is announced together with each option.
The autocomplete attribute with standard tokens such as email, given-name or postal-code satisfies the WCAG criterion on identifying input purpose. It lets browsers and assistive tools fill data automatically, which matters greatly for users with motor or cognitive impairments.
Error handling and validation
Errors are where inaccessible forms fail most often. An accessible pattern identifies the field, describes the problem in text and suggests a correction, and it makes the message reach assistive technology without requiring the user to search the page.
| Timing | Behavior | Accessibility assessment |
|---|---|---|
| On submit | All errors shown after submission | Reliable; add an error summary |
| On blur | Field checked when focus leaves | Good balance if messages are announced |
| On every keystroke | Message changes while typing | Disruptive for screen reader users |
| Native browser validation | Built-in bubbles | Inconsistent styling and timing across browsers |
After a failed submission, a robust approach places an error summary at the top of the form, moves focus to it, and lists each error as a link to its field. Each field also gets aria-invalid and an inline message tied with aria-describedby. Error states must not rely on color alone; an icon or text prefix such as “Error” is required.
Keyboard operation and focus
Every control must be reachable and operable by keyboard in a logical order that follows the visual order. Native elements provide this automatically; custom widgets such as styled selects, date pickers and toggle switches must replicate the expected keyboard interaction patterns and expose correct roles and states.
A visible focus indicator is mandatory, and WCAG 2.2 adds that a focused element must not be entirely hidden by sticky headers or overlays. Multi-step forms also require deliberate focus management: when a new step loads, focus should move to its heading so screen reader users know the context changed.
Relevant WCAG 2.2 criteria
The following success criteria are the ones most often tested in form accessibility audits. Level AA conformance, which includes all Level A criteria, is the common legal and contractual target.
| Criterion | Level | What it requires |
|---|---|---|
| 1.3.1 Info and relationships | A | Labels and groups exposed in markup |
| 1.3.5 Identify input purpose | AA | Autocomplete tokens for personal data |
| 3.3.1 Error identification | A | Errors described in text |
| 3.3.2 Labels or instructions | A | Visible labels and needed instructions |
| 3.3.3 Error suggestion | AA | Correction hints when known |
| 3.3.7 Redundant entry | A | No re-entering data already given |
| 3.3.8 Accessible authentication | AA | No cognitive test to log in, paste allowed |
Common mistakes
- Placeholder used as the only label, which leaves fields unnamed after typing starts.
- Required fields marked only by a red asterisk without text or programmatic state.
- Disabled submit buttons that give no explanation of what is missing.
- Session timeouts without warning, which erase long entries for slower users.
- Blocking paste in password fields, which breaks password managers and fails WCAG 2.2.
The fastest way to catch these issues is to complete the form with the keyboard only and then with a screen reader. Automated checkers find missing labels reliably but cannot judge whether error messages are understandable.
The short version
An accessible form is one that everyone can fill in. That includes people who cannot see the screen and people who cannot use a mouse. It also includes people who find complex instructions hard to follow.
It works like a good paper form handed over by a helpful clerk. Each box says clearly what goes in it. Related questions are grouped together. When something is wrong, the clerk points to the exact box and explains how to fix it.
Where it makes a difference
A municipal office moves its parking permit application online. During testing, a blind resident using a screen reader cannot finish the form: the vehicle registration field is announced only as “edit text”, and after submission the page reloads with red borders that are never announced.
The developers add visible labels linked to each input, group the permit type radio buttons in a fieldset with a legend, and add autocomplete tokens for name and address. On failed submission, an error summary receives focus and links to each problem field, which also carries aria-invalid and a text message.
In the follow-up test, the same resident completes the application in about four minutes without help, and keyboard-only users report that the form now behaves predictably.