Make a signup form understandable and usable

Start with labels that remain available

Every control needs an understandable purpose. W3C’s form guidance describes associating labels with controls, commonly through the HTML label element. For a straightforward field, a visible label such as Email address is easier to maintain than a hint that disappears when the person begins typing.

Instructions should explain the information needed and any relevant restrictions before an error occurs. Place them where they are likely to be encountered while completing the task. A decorative layout should not be the only way to understand which text belongs to which field.

Reduce the decisions without hiding the purpose

A form with fewer fields can still be confusing if its button or surrounding promise is vague. Decide what is required for the specific action and mark optional information clearly. If people can choose newsletter topics, give the group a meaningful heading and make the relationship between the choices explicit.

Use the wording of the actual task. A recurring newsletter, a one-off file request and a contact enquiry should not all have an unexplained Submit button. The contact-versus-subscribe guide helps separate those purposes before visual design begins.

A small wording specimen

Consider a short signup with a single required address field and an optional name. The copy below is an example of a coherent set, not a substitute for testing its actual markup and interaction.

• Visible field label: “Email address”.
• Optional field label: “Name (optional)”.
• Instruction: describe the publication and any confirmation step near the form.
• Button: name the operation, such as “Request the newsletter”, consistently with the process.
• Correctable error: identify the field and explain the supported correction.
• Overall result: explain whether the request was accepted, requires confirmation or could not be confirmed.

Worked example: an email field and topic choices

Imagine a specialist newsletter asking for an email address and offering optional topic choices. The label remains visible, the optional group explains what the choices affect, and the button names the subscription action. Supporting text explains the expected next step without burying it in an unrelated paragraph.

During review, ask someone to move through the form using the keyboard and explain the purpose of each control. Then examine the form with assistive technology where possible. Those checks can reveal different problems; success in one check is not a certificate that the entire experience meets every accessibility requirement.

A label, control and error example, described

The specimen below belongs to an invented newsletter called Harbour Notes. It is a description for editors and reviewers, not markup, and no real page was tested. It shows what a reviewer should be able to say about each part.

• Label: the visible text “Email address”, which stays on screen while the person types. A reviewer confirms that the control is given the same name when it is reached with assistive technology, rather than assuming it from the layout.
• Control: one entry area for one address, whose purpose fits in a sentence: it receives the address that should get Harbour Notes.
• Instruction beside the label: “Enter the address where you would like to receive Harbour Notes. We will send one message asking you to confirm.” The second sentence is right only if the hypothetical process includes a confirmation step.
• Optional field: a separate control labelled “Name (optional)”.
• Group: the heading “Topics (optional)” above the choices, then the sentence “These choices affect which items you receive; they do not decide whether you are subscribed.”
• Button: “Request the newsletter”, the operation the instruction describes.
• Error for the address control: “Email address: this does not look like an address. An address needs an @ sign followed by a domain, for example name@example.org. Please check it and try again.”

Three review questions follow from it. If the instruction were hidden, would the label alone still say what to type? If the error appeared on its own, would a reader know which control it concerns? If colour were removed from the message and the field border, would the meaning survive? The wording passes the last two by naming the field and stating the correction in words. It checks only the shape of an address; whether the person controls that address is a separate question for the email validation guide.

Make errors and outcomes available

W3C’s notification guidance emphasises clear overall and field-level feedback. A useful error identifies what needs attention and how to resolve it, rather than only changing a border colour. The result after submission should also be understandable when the page does not visibly navigate to a new screen.

Test a missing value, an invalid value and a service failure. Keep the focus order predictable and make sure the person can return to the relevant control. The confirmation guide explains why pending confirmation, active subscription and an uncertain connection need different messages.

Scenario: keyboard, error, correction

This scenario continues the Harbour Notes specimen. It is invented, describes what a reviewer would hope to observe and write down, and is not the record of a real session. Message wording is given in full because feedback cannot be judged from a description such as ‘an error appears’.

If the connection drops and receipt cannot be confirmed, the feedback should preserve that uncertainty: “We could not confirm that your request was received. Please check your inbox for a confirmation message before trying again. If nothing arrives, check the request’s status or use the contact page before resubmitting.” Keep this outcome distinct from a correctable rejection and from a received request awaiting confirmation.

• Enter by keyboard: the reviewer presses Tab until “Email address” is reached and types reader.example.org, forgetting the @ sign. Tabbing on, the reviewer leaves “Name (optional)” empty and chooses one item in the “Topics (optional)” group.
• Submit: the reviewer tabs to “Request the newsletter” and activates it.
• Overall message: “Your request has not been sent. One thing needs attention: Email address.” The reviewer notes where it appears and whether it can be found without a mouse. The guide does not prescribe where focus must land, only that the order stays predictable.
• Field message: “Email address: this does not look like an address. An address needs an @ sign followed by a domain, for example name@example.org. Please check it and try again.” It should be available when the control itself is reached, not only visible beside it.
• What survives: the control still holds reader.example.org so the mistake is visible, and the chosen topic is still selected. Clearing the form would turn a one-character slip into a retype.
• Correction: the reviewer returns to the address control with the keyboard, replaces the first dot with @ so the entry reads reader@example.org, and submits again. The point checked is that the way back to the relevant control does not mean starting the page over.
• Accepted result: “Request received. We have sent a message to reader@example.org asking you to confirm. Your subscription is not active until you confirm.” This is correct only when the process really sends that message; a private preview with nothing connected should say so instead.

Check the complete experience

Review the form at a narrow viewport and with enlarged text, including the space taken by a longer error message. Make sure important instructions remain readable and that controls are not obscured. A screenshot of an empty form cannot answer those questions.

Record what you tested and what still needs specialist review. Use the launch checklist to connect accessibility work to validation, delivery and support. Accessibility is part of operating a useful form, not a visual badge to add after the journey has been designed.

Write the scenario up without overclaiming

A hypothetical record for the scenario shows the level of detail that helps whoever makes the changes. Its last line matters as much as the others: listing what was not checked stops the next reader assuming that a keyboard pass covers other conditions.

Carry a record like this into the launch checklist, which connects accessibility work to validation, delivery and support.

• Case: keyboard-only completion with one invalid address and one correction.
• Expected: an overall message and a field message that both name Email address; the typed value and the topic choice preserved; a way back to the control; a final message that says confirmation is pending.
• Observed (invented for illustration): both messages appeared; the typed value was preserved; the way back to the control worked with the keyboard; the final message said confirmation was pending.
• Not yet checked: how the messages are announced with assistive technology, the narrow viewport, enlarged text and a longer error message. Any claim beyond this single route needs specialist review.