Can you see where the focus is, understand every field and recover from a mistake? These simple checks can uncover problems that an attractive form design hides.
Someone has read your service page and decided to get in touch. Then the form asks for a phone number in an unexplained format, clears the enquiry after an error or puts the submit button behind a floating widget.
At that point, the problem isn't a shortage of traffic. The website is making the next step unnecessarily difficult. Accessible forms help more people complete that step, including visitors using a keyboard, screen reader or enlarged text.
The checks below draw on W3C's form-accessibility guidance. They're a practical place to start, not a complete conformance audit or a legal opinion.
Keep the label where people can see it
A placeholder might look tidy until someone starts typing and it disappears. Each control needs a persistent visible label with the right programmatic association, so both the visitor and assistive technology can identify it.
Say which fields are required and explain any unusual input rules before submission. If a telephone field accepts international numbers, tell people what format works. Better still, avoid an unnecessarily narrow format that rejects otherwise usable contact details.
Ask whether every field is needed for the first response. A detailed discovery questionnaire may be useful later; it doesn't always belong in the initial enquiry.
Follow the focus through the whole form
Use Tab and Shift+Tab, without reaching for the mouse. Can you get to dropdowns, consent controls, upload buttons and submit? Does the order make sense?
Check that the focused control is visible, not covered by a sticky contact bar or chat widget. Don't remove focus outlines just to make a screenshot cleaner. A deliberate focus style can fit the visual design and make the form much easier to use.
Repeat the exercise at a narrow viewport and with zoom. Controls that look comfortable on a desktop can become awkward when space is limited.
Write errors that help someone finish
“Invalid input” doesn't tell a visitor much. Name the field, explain the problem and say how to fix it. Colour can support the message, but a red border shouldn't be the only explanation.
When several fields need attention, provide a useful overview and connect each message to the relevant control. Preserve valid entries where safe. Someone shouldn't have to rewrite a project description because one phone-number field failed validation.
| Try | Look for | A useful result |
|---|---|---|
| Keyboard only | Visible focus and logical order | Complete without a pointer |
| An invalid field | A specific, readable error | Correct it without starting again |
| Zoom and a narrow screen | Labels and controls remain readable | Submit isn't obscured |
| A test submission | A truthful status message | Enquiry saved and next step clear |
Make the result understandable, too
A spinning icon can show that something is happening, but it isn't enough for everyone. Loading, error and success states need appropriate feedback for assistive technology. Avoid announcing the entire form again whenever one field changes.
Check the recovery path after a connection failure. Can the visitor retry without sending accidental duplicates? Does a disabled button become usable again? Only confirm success when the application has actually accepted the enquiry.
A clear next step helps: explain what has been received and what happens afterwards, without promising an immediate reply unless that is genuinely available.
An automated scan won't tell the whole story
Use automated checks to catch defects, then add keyboard, screen-reader, zoom and mobile testing. Try long names, international contact details and Arabic enquiries where relevant. Short English dummy values can miss problems in real use.
Keep a record of what you tested, what didn't work and who will fix it. Repeat the checks when a booking embed, anti-spam control or new field changes the journey.
If you're reviewing your website with Gligx, this can sit within maintenance or a redesign. Pair it with an enquiry audit to check what happens after the form, including delivery and sales follow-up.
Sources and further reading
References checked on 23 October 2026.
Frequently Asked Questions
Can a placeholder do the job of a field label?
It shouldn't be the only label. Use a persistent visible label associated with the control; a placeholder can add a short hint.
Will an automated scan tell us if the form is accessible?
Only partly. Add keyboard, screen-reader, zoom and error-recovery testing to find problems a scan can't assess.
Should we clear the form after a validation error?
Keep valid entries where safe and explain what needs correcting. Making someone rewrite the whole enquiry creates unnecessary work.
Does following this checklist prove compliance?
No. It is practical guidance, not a full accessibility conformance audit or legal advice.