Accessible forms: design and test the complete journey
Labels, errors, confirmation and keyboard testing: practical form guidance illustrated by the MAHVU publishing project.
A good form lets a person understand the request, correct mistakes and know whether the submission succeeded. A short form can still be confusing; a longer one can be justified if every field helps complete the task. Define that task before choosing the layout.
Decide what the business actually needs
For a tradesperson's enquiry, the work requested, the town and a way to contact the customer may be useful. A photograph can help, but an optional attachment should not block an initial conversation. Mark optional fields clearly and explain file restrictions before upload.
Write the next step beside the form. An enquiry is not the same as a confirmed appointment. Use a button label that accurately describes what happens.
A real example: MAHVU
The MAHVU project needed blind members to publish news independently. I built a front-end publishing form so they could complete the task without using the WordPress administration interface. It was tested with several screen readers and then tried by members of the organisation.
Testing the home page alone would not have established that independence. The complete publishing journey mattered. The case study describes those usage tests; it does not claim an official accessibility audit or universal compliance.
Make fields understandable
Keep a visible label associated with each input. A placeholder can give an example, but disappears while typing. Group related choices, use appropriate input types and explain required information. The W3C forms tutorial provides the accessibility foundations.
<label for="email">Your email address</label>
<p id="email-help">We will use it to reply to your enquiry.</p>
<input id="email" name="email" type="email"
autocomplete="email" aria-describedby="email-help" required>
<button type="submit">Send my enquiry</button>
This example illustrates a labelled field. It still needs server processing, validation and an appropriate explanation of how personal information is handled.
Design failure states as carefully as success
Try an empty required field, an invalid address and an oversized file. Explain how to fix each error without relying on colour alone. Keep information already entered and associate the error with the field.
During submission, provide feedback without removing the whole form. If the connection fails, explain that delivery is unconfirmed and allow a retry. Do not display success until the server has accepted the request. Prevent accidental duplicate submissions, and verify actual delivery in a test environment.
Combine protection with usability
Browser validation helps the user; the server must independently validate input and permissions. Restrict uploads to the intended types and sizes. Keep private attachments out of publicly accessible folders. Test any anti-spam challenge with assistive technology as well as a mouse. See the website security guide.
Save a repeatable test scenario
Complete the form with the keyboard, correct deliberate errors, repeat on a narrow screen with enlarged text, and simulate a connection failure. Check focus visibility, feedback and the final confirmation. Record the browser and assistive technology used rather than labelling an untested form simply “accessible”.
For a booking, publishing or customer enquiry journey, my accessibility services begin with the task and the people who need to complete it.