Five things account for most form accessibility problems: labels that are visible and programmatically connected, errors described in text rather than by colour, full keyboard operability with a visible focus indicator, related fields grouped properly, and correct autocomplete attributes. Get those right and the form works for nearly everyone.
1. Real labels, permanently visible
Every field needs a label element associated with its input, so assistive technology announces the right thing when the field receives focus.
The recurring failure is using placeholder text as the label. It fails three ways at once: it disappears the moment someone types, so anyone interrupted has lost the context; it is usually too light to read comfortably; and it is not reliably announced as a label.
Placeholders are for examples and formats. Labels are for labels, and they should remain visible while the field is being completed.
2. Errors in text, next to the field
Three requirements that people tend to satisfy partially.
- Identify which field failed, in text. A red border alone is invisible to a screen reader and to anyone who does not perceive the colour difference.
- Explain what is wrong, specifically. "Invalid entry" is not an explanation. "Please enter a date as DD/MM/YYYY" is.
- Do not clear the form. Losing everything already entered because one field failed is the most reliable way to lose a submission, and it affects everyone.
Announce errors to assistive technology when they appear, rather than leaving a visual change nobody is told about.
3. Keyboard operability and visible focus
Every control must be reachable and operable by keyboard alone, in an order matching the visual layout.
The most common breakage is a removed focus outline. Designers dislike the default ring and remove it, frequently without replacing it, which leaves keyboard users navigating blind. If you remove it, replace it with something at least as visible, meeting the 3 to 1 contrast requirement for interface components.
Custom controls deserve suspicion here. A styled div behaving as a checkbox is usually not focusable and not announced correctly. Native form elements are accessible by default, which is the strongest argument for using them.
4. Grouping related fields
Sets of radio buttons and checkboxes need a group label, or the individual options arrive without context. Someone hearing "residential, commercial, industrial" as three options, with no announcement of the question they answer, has to infer it.
The mechanism is a fieldset with a legend. It is unfashionable markup and it exists precisely for this, and it also produces a clearer visual structure than a bare row of options.
5. Autocomplete attributes
Correct autocomplete values on common fields let browsers and assistive technology fill them automatically. This matters more than it sounds: for someone with a motor impairment, avoiding manual entry of a name, address, and telephone number is the difference between a form that is tedious and one that is exhausting.
It also benefits everyone by reducing typing and errors, and it is a WCAG requirement at AA for fields collecting information about the user.
Beyond the five
- Do not rely on colour alone to indicate required fields or errors. Add text or a symbol.
- Do not use a placeholder to convey formatting requirements that only appear before typing begins.
- Give adequate time. Session timeouts on long forms should be adjustable or removable.
- Make required fields clear before submission rather than only after failure.
- Size and space the controls properly, per the target size guidance in the thumb zone.
- Avoid puzzle-style verification. WCAG 2.2 addresses cognitive tests in authentication, and image puzzles exclude people unnecessarily.
The test
Complete your own form using only the keyboard, without touching the mouse, and deliberately trigger an error along the way.
Can you reach every field? Can you tell where you are at all times? When the error appears, do you know which field and why? Is what you already typed still there?
Most form accessibility problems surface within two minutes of trying this, and it requires nothing but the discipline to keep your hand off the mouse.
Frequently asked questions
What makes a web form accessible?
Five things cover most of it: visible labels programmatically associated with their fields, errors described in text next to the relevant field, full keyboard operability with a clearly visible focus indicator, related options grouped with a group label, and correct autocomplete attributes.
Can placeholder text be used instead of a label?
No. Placeholder text disappears as soon as someone types, leaving anyone interrupted without context, it is typically too light to read comfortably, and it is not reliably announced as a label. Placeholders are for examples and formats rather than labels.
How should form errors be presented?
In text, identifying which field failed and explaining specifically what is wrong rather than showing a coloured border alone. Previously entered information must be preserved, and the error should be announced to assistive technology rather than only appearing visually.
Why does removing the focus outline cause problems?
Because keyboard users rely on it to know where they are on the page. Removing it without providing a replacement leaves them navigating blind, so any custom focus style should be at least as visible and meet the 3 to 1 contrast requirement for interface components.
Why do radio buttons and checkboxes need grouping?
Because individual options announced without context leave the user inferring what question they answer. A fieldset with a legend supplies the group label, and it also produces a clearer visual structure than an ungrouped row of options.
How can I test my form for accessibility problems?
Complete it using only the keyboard without touching the mouse, and deliberately trigger a validation error. Check whether every field is reachable, whether you always know where you are, whether the error identifies the field and reason, and whether your entries were preserved.
West Coast Media Solutions Inc. builds websites for businesses across Canada. Platform policies change and enforcement varies; where legal actions are described they are identified by jurisdiction, since much of the published material on these topics is American and does not apply directly in Canada. This is general information rather than legal advice.
Want help getting this right?
We build websites and handle the work that surrounds them, so the details on this page get done properly the first time.
Start a Conversation