Forms sit at the centre of many important journeys: account opening, identity verification, contact requests and transactions. A form is not accessible just because every field is visible or has a placeholder. People need to know what each field is for, how to complete it, which information is required and how to recover from an error using their preferred input and assistive technology.
Give every control a persistent label
Connect a visible <label> to its control using matching for and id values. Placeholder text is not a replacement: it can disappear while typing and may be difficult to see. Use instructions for formats or restrictions, and connect them with aria-describedby when they add useful context.
<label for="email">Email address</label>
<input id="email" name="email" type="email"
autocomplete="email" required>
<p id="email-help">We will send confirmation to this address.</p>Keep labels concise and specific. If a field is required, indicate this in text and mark it programmatically where appropriate. Do not make an asterisk or colour the only explanation of a required field.
Group related questions and instructions
Use <fieldset> and <legend> for related controls such as a set of account options or contact preferences. This gives users context as they move among the controls. Put instructions before the fields they apply to, and avoid relying on visual position alone to connect help text and inputs.
Choose suitable input types and autocomplete tokens so browsers and password managers can offer appropriate assistance. Preserve entered data when validation fails; forcing someone to re-enter a long form can be a significant barrier.
Make validation specific and recoverable
When submission fails, explain what needs attention in text, identify the affected field and provide a concrete correction. “Invalid input” is not enough; “Enter a date in day, month and year format, for example 07/10/2026” gives a useful next step. Do not use colour alone to identify errors.
For longer forms, provide an error summary near the start after submission. Each summary item should link to the corresponding field. Set the field's invalid state and associate its error text programmatically. If you move focus to the summary after a failed submit, make the heading or container focusable and ensure keyboard users can continue from there. For dynamic validation, announce updates without repeatedly interrupting someone who is still typing.
- Keep the user's previous answers after an error.
- State what is wrong and how to fix it in plain language.
- Associate the message with the relevant field, not only with a red border.
- On success, confirm that the submission completed and describe the next step.
Support keyboard, touch and assistive technology
Complete the form using only a keyboard. Check logical tab order, visible focus, radio-button and checkbox operation, date pickers, custom dropdowns and dialogs. A custom widget must support the expected keyboard interactions and expose its role and state; when possible, prefer a native HTML control.
Test labels, instructions, required state, errors and success messages with screen readers on supported browser/device combinations. On phones, check that controls remain visible when the on-screen keyboard appears, labels are not clipped, and users can zoom without losing content or actions.
Check visual clarity and privacy
Ensure text meets the applicable contrast requirement—WCAG AA generally requires a 4.5:1 contrast ratio for normal text and 3:1 for large text. Non-text boundaries and focus indicators have separate requirements. Use clear spacing and headings, and do not make a timer or session expiry impossible to extend where a user needs more time.
Request only information the task needs. Explain why sensitive information is needed, avoid exposing it unnecessarily in error messages and use secure handling appropriate to the service. Accessibility and privacy should be considered together.
Before release, test a complete successful submission and common failure paths with keyboard and assistive technology. Our guide to WCAG accessibility checks covers broader page requirements, and our team can review a critical form journey.