Accessible forms that convert better for everyone

A form is a conversation with strict syntax. When the interface hides the question, rejects an answer without explanation or erases progress, people leave. The same failures are more severe for somebody using a screen reader, voice input, magnification or only a keyboard.

Accessibility and conversion are aligned here: reduce uncertainty, reduce effort and help the person recover from mistakes.

Use a visible label for every control

A placeholder is an example inside a field, not its name. It disappears during typing and can force somebody to delete their answer to remember the question. Keep a concise label visible and connect it to the input programmatically.

• Put instructions and format examples beside the field before the person needs them.
• Mark optional fields explicitly when most fields are required, or required fields when most are optional.
• Use the appropriate input type and autocomplete value so mobile keyboards and password managers can help.
• Do not block paste in password, email, card or verification-code fields.

Ask only what this step needs

For each field, name the decision or operation that uses the answer. If there is none, remove it. Information that is useful later can often be requested after signup, when the person understands the value of completing a profile.

Be careful with assumptions hidden in field design. A single “Full name” field is often more inclusive than forcing every culture into first and last name. Address formats vary by country. Phone numbers need country context. Test with the actual markets the service supports.

Choose validation timing deliberately

Do not show an error while somebody is still typing the first character. For format checks, validate after the field loses focus or on submission. For availability checks such as a username, wait until the input is plausible and announce the result without unexpectedly moving focus.

When submission fails, place a summary above the form, move keyboard focus to it and link each message to the relevant field. Keep an inline message beside the field as well. Colour can reinforce the state, but text or an icon must communicate it too.

Preserve work and make recovery safe

Never clear valid fields because one answer failed. For a long application, save a draft or warn before the session expires. If the server rejects a submission, distinguish a correctable field error from a service outage and tell the person whether their request was received.

Keyboard and screen-reader checks

1. Complete the form using Tab, Shift+Tab, arrow keys, Space and Enter without touching a mouse.
2. Check that focus order follows the visual order and that a visible focus indicator never disappears behind sticky content.
3. At 200% and 400% zoom, confirm labels, messages and the submit action remain usable without two-dimensional scrolling.
4. With a screen reader, confirm each control announces its label, requirement, hint and error once, in a sensible order.
5. Test browser autofill and password-manager behaviour on a real phone as well as desktop.

Measure the right drop-off

Track which field people last interacted with before leaving, how often validation fails and whether completion differs by device. Avoid recording sensitive field values in analytics or session-replay tools. A high error rate on one question is evidence to rewrite or remove it, not evidence that users need a sterner message.