A form is accessible only if people can finish it

Design the task before choosing controls

Consider a customer reporting a failed business application. They know what stopped working but may not know the product version, internal severity code or infrastructure owner. Making those fields mandatory shifts the company's triage work onto the person seeking help.

Ask for information that changes the next action. Explain unfamiliar requests beside the field and make optional information genuinely optional. A short form with precise questions often collects more useful evidence than a long form full of vague required fields.

Organise longer workflows into meaningful steps when that helps comprehension. Preserve earlier answers and show progress. Breaking a form into five screens does not improve accessibility if each screen forgets what the user already supplied.

Keep the control's meaning available

Use persistent visible labels with programmatic associations. A placeholder disappears as soon as someone types, precisely when they may need to check what the value represents. Group related choices so their shared question is available to assistive technology.

Choose established native or well-tested component behaviour before inventing a custom interaction. A visual dropdown can introduce keyboard and focus obligations that a standard selection control already handles.

The W3C forms tutorial provides the underlying label, grouping and notification guidance. The business-specific design still needs to decide which questions are necessary and how their answers affect the workflow.

Make errors part of the normal journey

Suppose a contact form rejects a telephone number but only adds a red border far above the submit button. A keyboard user may remain at the bottom with no explanation of why nothing happened. A screen-reader user may not hear the change at all.

Provide a concise error summary linked to the affected fields and specific messages beside them. Manage focus deliberately after failed submission and associate each message with its control. Avoid announcing an error on every keystroke while the person is still entering a valid answer.

Preserve all unaffected data. An error in one field should not erase a carefully written incident description or require another upload without explanation.

Explain uncertainty after submission

Disable or guard duplicate submission while a request is pending, but keep the state understandable. If the connection fails after sending, do not immediately tell the person to create a fresh request when the original might already exist.

Where the backend supports it, recover the result through a stable submission identity. Show a reference and next step only when the corresponding outcome is confirmed. A downloaded draft and a sent support request need different success messages.

Test the complete task on a small screen

Use the form with a keyboard, representative assistive technology, zoom and a narrow viewport. Open the mobile keyboard and reach the error messages and final action. Sticky controls must not cover the focused field or its instruction.

Automated checks can identify some missing associations, but they cannot determine whether a confused customer understands the question. Include task-based review with people who use the relevant interaction methods. The evidence should show that they can enter, correct and confirm the work, not just that the first screen passes a scanner.