How to plan an accessible website form

Plan a website form around the task someone is trying to complete, the information genuinely needed and the states they may encounter. Agree the labels, instructions, errors, confirmation and delivery owner before polishing the visual layout.

Define the request before choosing fields

Write one sentence describing what happens when the form succeeds. “Send a project enquiry to the delivery team” is specific enough to guide decisions. “Collect leads” leaves unanswered what the visitor expects and what the business needs to do next.

For every proposed field, identify who uses the answer and the decision it supports. If the team cannot explain why an answer is needed at this stage, consider leaving it out or asking later. A longer form may be justified by a complex task, but it needs an actual reason.

Put those decisions in the website form planning worksheet. It separates the visitor's experience from the internal work required after submission.

Keep a field's purpose visible

Give each control a clear label and ensure the label is associated with that control in the implementation. W3C's labeling controls guidance explains how semantic labels support understanding and interaction.

For a business enquiry, “Work email” and “What would you like help with?” tell the visitor more than vague labels such as “Details”. Use wording appropriate to the task: not every enquiry requires a work address, and a form should not reject a valid personal address simply because its label sounds businesslike.

Do not rely on placeholder copy as the only visible explanation. Once someone starts typing, they still need to understand what the field is for. Review the filled state as well as the empty design.

Explain requirements before they cause errors

Decide which answers are required and how that requirement is communicated. If a particular format or file constraint matters, put useful instructions where the person needs them. W3C's form instructions tutorial discusses general and field-specific guidance.

Avoid asking visitors to discover internal business rules by trial and error. If a budget question accepts a range, explain the available choices. If the team needs a reference link rather than a file upload, ask for that link directly instead of adding an upload control without an agreed handling process.

Keep instructions short enough to use while completing the task. A paragraph of policy detail inside every field will not fix an unclear request. Put wider context beside the form and keep field help specific.

Design the recovery path with the happy path

Specify what happens when a required answer is missing, an address cannot be used, a connection fails or the server rejects the request. These are different situations and should not all display the same generic warning.

W3C's user notification guidance covers clear feedback and associations between errors and their fields. Ask the implementer to demonstrate how people find a problem, understand the correction and continue without unnecessarily re-entering valid answers.

For an illustrative enquiry form, an empty email field might say “Enter an email address so we can reply.” An invalid address might say “Check the email address, for example name@example.com.” These are sample messages to adapt to real validation rules, not a complete validation implementation.

If the request was not accepted because of a temporary service failure, say that clearly and provide the next available action. Do not show a success confirmation merely because the visitor pressed the button.

Make the action and confirmation truthful

Choose a button label that describes what the action does. “Send project enquiry” distinguishes sending a message from booking a meeting or starting an account. The exact wording should follow the service being offered.

The confirmation should explain the accepted outcome and the next step. Promise a reply time only when the business has agreed and can operate it. A message such as “Your enquiry was received” also needs a defined system event behind it: is the record stored, routed or merely queued?

Agree which state the interface can honestly confirm. Then test the next internal step separately. A successful browser response does not prove that a person saw the message or that a mailbox received it.

Work through a small fictional example

Imagine a fictional design consultancy offering an initial project conversation. Its team decides that name, reply email and a short description are needed to route the request. A website link is optional because some prospective clients do not have a site yet.

The first draft requires a phone number and an exact launch date. During planning, nobody can identify a routing decision that needs either answer immediately. The team makes those questions part of the later conversation. This is an example of a decision process, not evidence that fewer fields always improve conversion.

The review record names the delivery owner, defines accepted and failed states, and includes messages for missing email and temporary failure. The team then tests the built form with synthetic data, including an optional link left blank. The worksheet provides space to record that evidence; this fictional example does not claim those tests happened on a client project.

Review keyboard and mobile use in the build

A static design cannot demonstrate the whole interaction. In the implemented form, review the order in which controls receive focus, whether the focus location stays visible, and whether labels and help remain available when zoomed or viewed on a phone.

Have an accessibility reviewer evaluate the relevant semantics and assistive-technology behavior. Test error recovery as a complete task, including finding the error and submitting again. Automated checks are useful evidence for their scope, but they do not replace this task review or establish conformance on their own.

Record the browser, device or viewport, input method, expected outcome, actual outcome and issue owner. Use the same task wording when comparing later revisions so the review remains meaningful.

Include delivery and ownership in acceptance

Identify who owns the form endpoint, submission records, notification routing and ongoing monitoring. Record where information goes and which team can resolve a failed submission. Decide how test messages will be identified and removed through the approved process.

Make data handling an explicit project decision with the responsible business owner. Collect only information needed for the agreed workflow; avoid putting sensitive real information into a planning worksheet or test run. A form design article is not a substitute for the organization's applicable privacy and retention decisions.

Use the service page framework to connect the form to a clear offer and the website launch checklist for the wider release review. A useful acceptance record covers both the visitor's task and what the business does with the request.

Primary W3C guidance was checked on 29 October 2026. This is a planning framework with a fictional example, not an accessibility certification or a claim that a particular form backend was tested. The cover is an AI-generated editorial photograph.

The Blitz Studio team

We design brands, build websites and engineer digital products.

Talk about your next project