You have filled in a form, pressed Submit and received a red message: “Invalid input.” Lovely. Which input? Invalid in what way? Have we offended the form personally?
People come to forms to accomplish something: book an appointment, apply for a service or ask for help. Accessible form design makes that task easier to understand and complete, including when something goes wrong.
Before typing: explain what the form needs
Give each field a clear, persistent label. A placeholder can offer an example, but it disappears while someone types and should not carry the entire explanation.
Explain requirements before they become errors. Show a required date format beside the field. Communicate file-size limits before someone selects a document and waits for an upload.
Ask whether every question is necessary. Even optional fields consume attention. If the team cannot explain how an answer will be used, consider removing the question or asking it later.
During entry: make the interaction predictable
Use controls that match the information requested. Let people move through the form with a keyboard, see where focus is and activate controls without needing a mouse.
Associate labels and instructions with inputs in the implementation. A visually nearby label alone does not guarantee that assistive technology will connect it to the correct control.
Choose validation timing deliberately. An error appearing while someone is still typing can feel like a passenger correcting every turn before you reach the intersection. Help at a moment when the person can reasonably act on the feedback.
After a mistake: support recovery
Here is an illustrative email-field example:
Before: a red border and “Invalid.”
After: “Enter an email address in this format: name@example.com.” The field remains labelled “Email address,” with the message associated with it.
Identify the problem in text; colour can reinforce it. For a longer form, an error summary can help people reach the fields needing attention. Make focus behaviour intentional, so correction does not become a search exercise.
Keep valid information whenever possible. Clearing the entire form after one error turns a small correction into a repeat performance nobody asked for.
Explain completion and the next step
A service request may need confirmation that it arrived, what happens next and an accurate response expectation. Make meaningful status feedback available to people who do not see the visual update. Avoid excessive announcements that interrupt the task.
A practical form checklist
- Does every field explain what to enter?
- Are requirements and optional questions clear?
- Can the whole task be completed using a keyboard?
- Do errors identify the problem and offer useful guidance?
- Does correction preserve information already entered?
- Can people understand success and the next step?
The W3C WAI Forms Tutorial is a useful reference. Combine implementation review with testing involving people with disabilities. A checklist alone does not establish complete accessibility.
For business evaluation, compare completion, errors or recovery against a baseline rather than assuming a conversion increase. Trust and comprehension also shaped the research questions in my Inclusive Digital Banking case.
Review your most important form as a complete journey. Start where someone is most likely to need help.