Accessible Form Design: Labels, Instructions, Groups and Completion

Make every field answer three questions: what information belongs here, what format is accepted and what happens after submission. Keep those answers visible and connect them to the control in the markup. Then test the whole form with keyboard navigation, zoom, autofill and a screen reader.

Begin with the information the service actually needs. Removing an unnecessary field reduces work for everyone and eliminates another opportunity for an error. For each retained field, record why it is collected, whether it is required and how the entered value will be used.

Give each control a persistent label

Use a visible label that describes the field. Connect it explicitly with a for attribute matching the input’s unique id, or use an appropriate implicit label. Keep the visible wording concise enough to recognize in an error summary and in spoken output.

<label for="contact-email">Email address (required)</label>
<p id="contact-email-hint">We will send the booking confirmation here.</p>
<input id="contact-email" name="email" type="email"
       autocomplete="email" required
       aria-describedby="contact-email-hint">

This example identifies the field, explains its purpose and provides the appropriate input type and autocomplete token. The visible “required” text and the native required attribute serve complementary audiences. Keep the surrounding instructions readable when the field already contains a value.

A placeholder can offer an example, but it disappears as the user types and should not carry the only label or essential instruction. Test the form after filling every field. If the meaning of a value becomes unclear at that point, the persistent labeling needs work.

Put instructions before the difficulty

Explain a restrictive format before asking the user to submit it. For a date, show the expected order in the label or hint. For an upload, state the accepted formats and size limit next to the control. Use the actual service limits and keep the client and server messages consistent.

Accept reasonable input variations when the underlying task allows them. For example, avoid forcing people to remove spaces from a telephone number merely because a validation expression was written narrowly. Check international names, addresses and number formats against the service’s genuine requirements before rejecting them.

Associate a field’s hint with aria-describedby when that relationship helps assistive-technology users. Keep general instructions near the start of the form and field-specific instructions beside the relevant control. Long policy text belongs in an appropriate separate explanation, with a clear connection to the decision it affects.

Use a fieldset and legend for a related radio-button group or other controls that need a shared question. Each option still needs its own label. Keep the legend meaningful when read with any one option.

<fieldset>
  <legend>How should we contact you?</legend>
  <label><input type="radio" name="contact-method" value="email"> Email</label>
  <label><input type="radio" name="contact-method" value="phone"> Phone</label>
</fieldset>

Check how the group behaves when the user moves into it, changes the selection and leaves it. If choosing Phone reveals another field, place that field logically in the document and keep its required state consistent with the selection. Returning to Email should not leave an invisible phone field blocking submission.

For a large form, group by the task: contact information, delivery details and review. Use headings and a clear sequence. A compact layout is useful only if the grouping remains understandable at narrow widths and when labels wrap to multiple lines.

Use input types and autofill purpose together

Choose a native input type that matches the data, such as email, tel or date, while testing its behavior in supported browsers. Use appropriate autocomplete tokens for fields collecting recognized information about the user. WCAG 1.3.5 addresses identifying those input purposes programmatically where the technology supports it.

The type and the purpose are different. An email field may contain the user’s address or another person’s address; the autocomplete token should reflect the intended purpose. Keep autocomplete available where it helps users avoid repetitive entry, and test the completed values rather than assuming autofill worked because a token exists.

Use a text input for identifiers that are strings even when they contain digits. A reference number with leading zeros should remain intact. Choose input modes and validation according to the expected data rather than using a numeric control solely to display a number keypad.

Keep multi-step forms consistent

Name each step and show where the user is in the process, such as “Step 2 of 3: Delivery.” Preserve valid information when the user moves back to edit it. Before a final action, provide the review and correction opportunities appropriate to the transaction.

Reuse information already provided in the same process when required by WCAG 3.3.7, subject to its exceptions. An explicit option to use the delivery address for billing is easier than requiring the user to remember and retype it. Test a later change to the original address so reused values do not become silently stale.

If the process crosses into a vendor-hosted step, include that transition in testing. Check labels, focus, saved values and the return path. The user experiences one task even when several systems supply its screens.

Design the error and success states

Write error messages alongside the form specification. Identify the field, describe the problem and explain the correction. Keep valid data available. Use an error summary when several fields need attention, with links that take the user to the affected controls.

Associate each field’s error text programmatically and update its invalid state when appropriate. Use color as an additional cue alongside text. Test whether the user hears the error at the right time and can return to the field without searching the whole page. The error-recovery guide gives a more detailed implementation pattern.

After success, say what happened and what the user can do next. For a booking request, distinguish a submitted request from a confirmed booking. Use the actual service outcome so the confirmation does not create a false expectation about availability, payment or response time.

Test the completed task in several states

Create a small test set: an empty required field, an invalid format, valid input, a change on an earlier step and a server failure. Include a long name or address and autofilled values. Test at a narrow viewport and with zoom so instructions and errors remain next to the controls they describe.

With the keyboard, check the order and visible focus. With a screen reader, check names, required state, hints, group labels and errors. Ask participants with relevant access needs to complete realistic tasks when evaluating the service, and record where the interface makes them work unnecessarily.

Keep the tested states with the component documentation. When a field’s business rule changes, update the hint, validation, server response and tests together. That keeps the form’s explanations aligned with what the service actually accepts.