Accessible forms: How to remove the barriers between users and submission
A form may look simple yet still be difficult to understand, navigate and submit. Here is a practical method for making the entire form journey accessible.
Category: Accessibility
The contact form is often where the website is meant to turn interest into action. Users want to place an order, apply, register or ask for help. If the form is difficult to understand or use, the problem goes beyond a poor user experience. The organisation also loses enquiries, applications and sales.
Accessible forms are therefore about more than colours and technical validation. The entire form journey must work: from the moment users understand what to fill in, to correcting errors and seeing a clear confirmation. WCAG provides requirements and principles, but the practical work must be based on the task users are trying to complete.
Start with the task, not the form fields
Before assessing code, contrast and screen readers, ask a simpler question: What does the organisation actually need to know right now?
Many forms become inaccessible because they are unnecessarily extensive. Each additional field requires reading, understanding, navigation and a decision. This particularly affects users with impaired vision, motor difficulties, reading difficulties, concentration difficulties or limited digital experience.
Distinguish between information you need to process the enquiry and information that may merely be useful. Information that can be collected later does not necessarily need to be included in the first form.
A useful review of each field
- Why do we need this information? An unclear answer suggests that the field can be removed.
- Does the user need to answer now? Some things can be clarified in the next step or in a conversation.
- Could the field be misunderstood? Internal terms and technical jargon should be replaced with the user's language.
- Can we accept multiple formats? Phone numbers, organisation numbers and dates should not be rejected because of harmless variations.
A shorter form is not automatically accessible, but it reduces the number of possible barriers and makes testing more manageable.
Give every field a clear, persistent label
A field must have a visible label that tells users what to enter. An example inside the field is not an adequate substitute. Example text often disappears when users start typing, may have low contrast and is not always presented well by assistive technologies.
The label should be short and specific, such as “Email address” or “Describe what you need help with”. If the field requires a particular format, the instruction should be visibly placed nearby before users fill it in.
The technical association between the label and the field is crucial for screen readers. When the association is correct, the assistive technology can present the field's name, type, status and any instructions. Visual proximity alone is not enough.
Clearly indicate what is required
Do not distinguish between required and optional fields solely by colour or by a symbol without an explanation. Write “required” or “optional” consistently. It is often tidier to mark the few optional fields when most responses are required.
Users should be told about password, file type or text length requirements before submitting. It is frustrating to learn the rules only after an answer has been rejected.
Build a predictable keyboard flow
An accessible form must be usable without a mouse. Users must be able to move through fields, checkboxes, options and buttons in a logical order. Focus should remain visible at all times.
The order should follow the visual and linguistic structure. If keyboard focus jumps from the name to the submit button and then back to the address, the form becomes difficult to understand. Avoid creating an artificial focus order to compensate for an illogical page structure.
Pay particular attention to custom dropdown lists, date pickers, file uploads and radio buttons. Such components may look good but lack the expected keyboard interaction. Standard form controls are often the safest starting point when they meet the need.
A simple keyboard test
- Reload the page and put the mouse aside.
- Move through the entire form using the keyboard.
- Check that the focus indicator is easy to see.
- Try all options, buttons and any help text.
- Submit the form with empty or invalid fields.
- Check that you can reach the errors efficiently and correct them.
- Submit again and check that the confirmation is perceived.
Also test backwards navigation. This often reveals focus traps and components that do not behave as expected.
Contrast applies to more than text
Good contrast must cover the text, but also the information that makes the form usable. Field borders, focus indicators, error icons, checkboxes and selected states must be visible against the background.
A common problem is light-grey field borders on a white background. Users can see the text, but not where the field begins and ends. Another problem is a focus indicator that disappears against the button or field surrounding it.
Color should not be the only way to communicate status. A red field border says little to users who cannot perceive the color, and nothing to a screen reader. Combine color with clear text, and preferably a visual symbol when it helps users understand more quickly.
Create error messages that help users move forward
“Invalid value” describes the system’s response, not what the user should do. A good error message says which field has a problem, what the problem is, and how it can be resolved.
Example: “Enter the email address with both an @ and a domain name.” This is more useful than “Email is invalid.” For date fields, the message can show the expected order without requiring an unnecessarily strict input format.
When submission fails, errors should be shown both in a summary and beside the relevant fields. An error summary at the top provides an overview, while the message beside the field provides the necessary context. The error summary should make it easy to go directly to the field that needs correcting.
Do not delete correct information because one field contains an error. Having to complete the entire form again is particularly demanding in lengthy applications and ordering processes.
Make sure screen readers detect changes
Screen reader users do not necessarily notice when new content appears elsewhere on the page. This includes error messages, price changes, new fields and confirmations after submission.
Dynamic changes must therefore be handled so that assistive technologies can detect them without requiring users to search through the entire page again. At the same time, you should avoid having every minor change read out immediately. Too many interruptions can make the form more difficult to use.
Test the most important steps with a screen reader, not just the initial reading of the fields. In particular, check that:
- field names and field types are presented correctly
- required status and instructions are read aloud
- groups of options have a clear shared question
- error messages are associated with the correct field
- new fields and status messages are detected
- the confirmation after submission is clear
Avoid letting time limits and security measures lock users out
Time limits can be problematic for people who read slowly, use assistive technologies or need breaks. If a session must expire, users should be warned and given a genuine opportunity to extend it. Also consider whether entered information can be preserved securely.
Security checks require the same careful consideration. Tasks that require interpreting unclear images, reacting quickly or using precise motor skills can prevent real users from proceeding. Choose solutions that protect the form without making human verification the user’s main task.
Test the entire form journey with realistic errors
A technical check can reveal missing labels and some contrast issues, but it cannot tell you whether the form is understandable. Therefore, combine automated checks with manual testing and task completion.
Create a few standard test scenarios. One user enters a phone number with spaces. Another skips a required field. A third uploads the wrong file type. Also test what happens with a slow response, a double-click on the submit button and use of the back button.
Include people with different needs when the form is important to the organisation. This can reveal problems the team does not notice itself, such as unclear questions, unexpected terminology or a confirmation that does not explain what happens next.
Make accessibility part of form management
A form is rarely finished forever. New fields, integrations, campaigns and spam measures can change how it works. The organisation should therefore assign clear responsibility for content, technology and ongoing follow-up.
Define a minimum requirement for all forms: visible labels, understandable instructions, a logical keyboard order, clear focus, sufficient contrast, specific error messages and a confirmation that works with screen readers. Test again whenever the form or the underlying component changes.
The most important goal is not for the form to look correct on a checklist. The goal is for more people to be able to understand the task, complete it and know that their submission went through.
