Designing Accessible Forms
By Maksym Bardakh · Co-founder & President
In short
Accessible forms start with persistent visible labels bound to their controls, not placeholder text that vanishes on focus. Errors must be announced, explained in plain language, and tied to the field that caused them. Logical focus order, grouped related fields, and instructions before the input rather than after let people using keyboards and assistive technology complete the form without guessing.
Labels that persist and associate
A label tells the user what a field is for, and it must remain visible while they fill it in. Using placeholder text as a label is a common and damaging shortcut: the hint disappears the moment the person starts typing, leaving someone who looked away with no way to recall what the field wanted. Placeholders also tend to have poor contrast and are not reliably announced by assistive technology.
Each label must be programmatically associated with its control so that activating the label focuses the field and a screen reader announces the two together. A visible label that is not connected in the markup helps sighted users but not those relying on assistive technology.
Errors that explain and point
When validation fails, the form must do three things: announce that an error occurred, explain what is wrong in plain language, and identify which field is affected. A generic message at the top saying something went wrong forces the user to hunt. Tying the message to the specific field, and moving focus there, turns a dead end into a recoverable step.
- State the problem in plain language, not a code or jargon.
- Associate each error with its field so assistive technology announces it.
- Preserve the user’s entered data rather than clearing the form on error.
Order, grouping, and instructions
Keyboard users move through a form in focus order, so that order must follow the visual and logical sequence. Related fields, such as the parts of an address or a set of radio options, should be grouped so their relationship is conveyed. Instructions that a field needs must appear before the input, where they are read in time to be useful, not after it where a screen reader reaches them too late.
Key takeaways
- Use persistent visible labels associated with their controls, not vanishing placeholders.
- Announce errors, explain them plainly, and tie each to its field.
- Preserve entered data when validation fails.
- Follow a logical focus order and group related fields.
- Place instructions before the input and test with keyboard and screen reader.
Frequently asked questions
- Why are placeholders bad as labels?
- They disappear when the user types, often have poor contrast, and are not reliably announced by assistive technology, leaving people without a persistent cue.
- How should form errors be presented accessibly?
- Announce that an error occurred, explain it in plain language, associate it with the specific field, and move focus there while preserving entered data.
- Where should field instructions appear?
- Before the input, so they are read in time to be useful, rather than after it where a screen reader reaches them too late.
References
About the author
Maksym Bardakh
Co-founder & President
Maksym is a software engineer and product strategist focused on executive-function and behavioral system design. At BBMM he leads product direction across Flowo, TextPack, and Pillow, working at the intersection of human cognition and durable interface design.