An accessible form lets people understand the fields, move through them with a keyboard and correct mistakes without losing what they typed. You do not get there just by changing colours. Check the labels, the focus, the messages and the submission confirmation with real tests. An automatic tool helps find problems, but it does not replace checking the whole journey.
The person trying to write to you should not have to guess where the cursor is or what a red border means. They may use a screen reader, enlarge the text or navigate without a mouse. They may also be filling in the form on a phone in poor light. Difficulties in using a form take very different shapes.
What is the difference between a nice-looking form and an accessible one?
Appearance is one part of usability. A design can have careful typography and still fail to give each field an understandable name. Text that sits inside a box and disappears as you type does not meet every need. The information must stay available during the task.
The W3C forms guide explains how to identify controls and associate them with their labels. That association lets different ways of interacting understand the purpose of the field. Labelling form controls, accessed on 10 October 2026. It is not an ornament added at the end of the design.
Imagine a training academy that receives enquiries about courses. Its form asks for name, contact details and course, but each label is written as decorative text outside the control. A visual check may not spot the problem. The experience changes when someone uses a technology that needs to interpret the relationship between the two.
The aim is not to fill the page with instructions. It is to give the right information in the place where it is needed. If a field asks for a phone number so that you can call, say so. If the phone number is optional, say that. If email and a message are enough, do not ask for other details just because the form builder includes them by default.
How do you check labels and keyboard navigation?
Start with a simple test: put the mouse down and work through the form. See whether you can reach every control, tell where you are and activate the submit button. The visible focus is the signal of your position, not a graphic nuisance to be removed. If it disappears when the style changes, navigation can become uncertain.
Do not turn that first test into a certificate. It is there to find obvious barriers and decide what needs a deeper review. Check the order of controls, checkboxes, drop-downs and any selection panel that opens. A pop-up can be manageable with a mouse and hard to leave with a keyboard.
In the academy example, choosing the course could open a custom list. Check that the person understands what has been chosen and can change it. It is not enough for the value to appear painted on a card. The state also has to be understandable for people who do not use that visual presentation.
Review the instructions next to the field they refer to. An explanation at the foot of the page can go unnoticed. Avoid relying on phrases such as "press the button on the right" when the layout changes on mobile. Identify the action by its name, which should stay consistent across screens.
You can note each obstacle with the action taken and the result observed. "I can't open the list with the keyboard" is more useful for fixing than "bad accessibility". Include the device, browser and test context. If the issue changes with a particular combination, that detail avoids blind repairs.
What happens when someone makes a mistake?
Try an incomplete email address and leave a required field empty. See whether the form explains the problem and lets you correct it. The message should help people carry on, rather than just punishing the error. "Enter an email address with its domain" guides better than a generic warning that does not point to any field.
WCAG 2.2 includes criteria on identifying errors and providing labels, instructions and suggestions where appropriate. W3C reference, accessed on 10 October 2026. It is a technical reference: using it does not by itself allow you to claim that a website meets all the applicable rules.
Another important question is what the form keeps. If someone writes a long message and loses everything when correcting the phone number, you are making them repeat their work. In the academy example, that message could explain a need about timetables. The content should not disappear because another box has the wrong format.
Think about service errors too. A connection failure and a mistyped value are not the same thing. The first needs to explain that sending could not be completed; the second asks for a specific correction. Do not confirm that you have received the message if the system does not know. A false confirmation creates expectations nobody will meet.
The W3C guide on notifications describes ways to communicate the results and errors of a form. User notifications, accessed on 10 October 2026. When you review your page, check that these messages are perceivable through the relevant ways of interacting.
How do you test submission without relying on a score?
Automatic checks can locate known code defects, but they do not fully understand the task your visitor is trying to complete. A high score does not show that the message arrives or that the instructions are understandable. Combine technical review with journey tests.
| Journey | What to observe | What to record |
|---|---|---|
| Keyboard | Order, focus and activation | Control where the blockage appears |
| Enlarged text | Legibility and layout | Content that overlaps or disappears |
| Assistive technology | Names, states and messages | Information that is missing or confusing |
| Error in one field | Explanation and recovery | Whether the typed message is kept |
| Successful submission | Confirmation and receipt | Result checked at both ends |
Use fictitious data and a message clearly marked as a test. Warn whoever receives the forms so that they do not treat it as a sales enquiry. Keep a reference for the test and check receipt. Afterwards, delete the test data following the business's procedure, without mixing it with genuine enquiries.
If you need a full assessment, include people and devices suited to the scope. Do not simulate the user experience just by resizing a window. A short test can detect problems, but its report should explain its limits and what remains unverified.
Where do you start if the form is already live?
Give priority to blockers: inaccessible controls, loss of information, errors without explanation and the lack of a reliable confirmation. Then review clarity, comfort and visual consistency. That sequence helps restore the main function before polishing details that do not stop people finishing.
Try to reproduce the issue before touching the code. Keep a recoverable copy, apply the change and repeat the same test. A fix needs to show which journey it improves. Changing several components at once without a test case makes it hard to know what solved the problem and what may have introduced another.
In Spain, Law 11/2023 covers certain products and services and contains conditions and exceptions that require reviewing the specific case. Specific obligations are not identical for every small business or every form. Consolidated text in the Spanish official gazette (in Spanish). This article offers general information, not legal or professional advice.
How have we approached it at meiika?
Our website service lets us start a conversation about the task your page should solve. To review a form, describe who uses it and what happens when they try to send it. We are not presenting a certification here, nor an audit carried out for a client.
We can start by understanding one specific blockage: choosing a course, attaching information or sending an enquiry. The problem must be described before deciding on the solution. Share the journey without including visitors' personal data; an anonymised screenshot or a fictitious example avoids passing on unnecessary information.