Accessible Website Forms
Make Enquiries Easier
To Complete

A customer reaches your website, understands the offer and decides to get in touch. Then the form creates a problem. The labels disappear as they type. An error is shown only in red. The keyboard cannot reach the submit button. Their details vanish when they try again.

These are barriers at the exact moment your marketing should make the next step easier. They can affect people using assistive technology, people navigating without a mouse and people simply trying to finish a task on an awkward screen.

An accessible form deserves the same attention as the headline that sends visitors to it. This guide turns a form review into a practical workshop your marketing team and developer can work through together.

Start With The Standard, Then Examine The Journey

W3C published WCAG 2.1 as a Recommendation in June 2018. Relevant criteria address keyboard operation, visible focus, labels or instructions, error identification and contrast. The standard specifies a minimum contrast ratio of 4.5:1 for normal text at Level AA, with defined exceptions. WCAG 2.1, 2018 Recommendation.

Those criteria provide a technical reference. Your review should also consider the actual customer task: can someone understand the questions, supply the required information, correct a mistake and know whether the request succeeded?

A quick workshop can uncover useful improvements. It does not establish that an entire website conforms to every applicable accessibility requirement. Record the scope honestly and involve people with relevant accessibility expertise for a fuller assessment.

Workshop One: Question Every Field

Print the form or copy its questions into a document. Beside each field, write the decision it helps your team make. If nobody can explain why it is needed before the first conversation, consider moving it later.

An imaginary commercial catering enquiry might need the event date, approximate headcount, location and a way to contact the organiser. It may not need the organiser's full billing address before anyone has confirmed availability.

Discuss ambiguous questions. Does “budget” mean food only or the entire event? Does “guests” include children and staff? Add brief instructions where the answer affects the proposal. The aim is to reduce unnecessary effort without stripping out information that helps the business respond properly.

Workshop Two: Try The Form Without A Mouse

Ask your developer to demonstrate the path from the page heading through every field to the final confirmation using a keyboard. Record places where the next action becomes unclear or unavailable.

Use a realistic task rather than clicking through mechanically: “Ask whether catering is available for a workplace lunch for about thirty people next month.” This gives the reviewer a reason to interact with date controls, choices and submission states.

Keep the observation separate from the fix. “Could not tell which control was active” is an observation. The developer can then investigate the cause and propose a correction. That makes the issue easier to reproduce than “the form feels bad.”

Workshop Three: Make Labels And Choices Unambiguous

Compare what a customer sees before and after entering information. A field should remain understandable throughout the task. Ask the developer to confirm that controls have appropriate programmatic labels as well as clear visible wording.

Review choices from the customer's perspective. An internal term such as “activation type” may mean nothing to a person arranging a lunch. “What kind of event are you planning?” gives them a clearer starting point.

Avoid forcing a false answer. If the exact date is undecided, provide a sensible way to say so when your process permits it. Otherwise, customers may enter an arbitrary date and your team may treat it as confirmed information.

Workshop Four: Deliberately Make A Mistake

Submit the form with a required answer missing and with an invalid email address. Observe what happens to the information already entered and how the customer is told to correct the problem.

Write the error message in the language of the task. “Enter an email address such as name@example.com” is more helpful than an internal validation code. Confirm with your developer that the error can be identified by people using assistive technology.

Then submit successfully. The confirmation should explain whether the enquiry was received, what happens next and how to contact the business if needed. Do not promise a reply time that the team cannot consistently support.

Workshop Five: Test The Form In Its Real Surroundings

A form does not operate in isolation. A fixed banner can cover the bottom of the screen. A chat widget can sit over the submit button. A promotional popup can interrupt the task halfway through.

Try the page on a narrow screen, with enlarged text and with the other site features active. Check whether instructions and confirmation messages remain readable. Ask a developer to investigate layout problems instead of assuming the customer can simply rotate the phone.

Give particular attention to any date picker, file upload or third party booking component. These controls often sit outside the main page design, but they still determine whether the customer can finish.

Prioritise Repairs By Their Effect On The Task

Use three practical categories: prevents completion, creates uncertainty and causes avoidable effort. A problem that blocks submission should generally take precedence over a minor visual inconsistency.

For each issue, record the page, device or interaction method, reproduction steps, owner and expected behaviour. Include a screenshot where useful, but do not rely on an image alone to explain an interaction failure.

After a repair, repeat the original task. A change that looks correct in a design preview may behave differently in the live form. Include people with disabilities in testing where possible and compensate them fairly for their time and expertise.

Measure The Business Outcome With Care

Track successful enquiries, repeated submission problems and the amount of clarification your team needs after receiving a request. A shorter form is not automatically a better form if it creates unusable enquiries.

Your next move: complete your own enquiry process using only a keyboard, deliberately trigger an error and read the confirmation. Bring the observations to your developer. Those three checks can start a much more useful conversation than “make the form easier.”

Written for the 2020 archive series. Platform references reflect the assigned period.