Writing

Our form review began with an easy request: make the error messages clearer. Following that thread led us through labels, instructions, keyboard navigation and the layout itself. The message was only one part of the experience.
We replaced placeholder-only fields with visible labels. Hints moved beneath the relevant inputs and stayed visible after typing began. A person should not have to clear a field to remember what it was asking for.
For a delivery date, “DD/MM/YYYY” was less helpful than a visible example and a clear explanation of which dates were available. We separated formatting instructions from the reason we needed the information.
A failed submission now keeps everything the person has entered. An error summary appears above the form, links to each field and receives keyboard focus. Each message also appears beside the input it describes.
“Enter an email address such as alex@example.com” gives someone a next step. “Invalid input” leaves them to diagnose the problem.
We stopped using colour as the only signal. The field label, message and visual treatment work together, so the problem remains understandable in different viewing conditions.
I walked through the form using only the keyboard, then repeated the task with a screen reader alongside a colleague. We found a hidden button with a confusing name and a focus indicator clipped by its container.
These checks belong in the design process as well as implementation. Our handoff now includes the order of focus, the wording of errors and what happens after a successful submission. A form is complete when someone can understand and finish it.