Accessible business forms
Review the form in its least comfortable state
Empty, invalid and interrupted forms expose weaknesses that a completed demo hides. Assess the actual journey with keyboard, touch and assistive technology.
In this article
Start with the questions and labels
Read each question without looking at its placeholder. The label should still identify what is required, and any unfamiliar instruction should remain available after typing.
Check related choices as a group. A series of radio buttons needs the shared question as well as individual option labels. Ensure the visible wording and accessible name support the same action.
Ask why every required field is necessary at this stage. Remove or defer questions that the user cannot reasonably answer and that do not change the immediate business decision.
Trigger every class of failure
Submit missing and malformed values, then cause a server-level rejection. Verify the error summary, field associations and focus behaviour for each path.
Keep one long valid answer in the form throughout. It should survive unrelated corrections and network errors. Test uploaded-file handling separately because browsers and backend storage may impose different recovery constraints.
Delay the final response and activate the action again. Confirm the duplicate-handling behaviour and the message shown if the outcome remains uncertain.
Inspect the layout with real interaction
Use a narrow viewport and open the mobile keyboard. Reach the focused field, its instruction and the submit action without obscuring overlays.
Enlarge text and inspect long messages. Fixed heights and absolute positioning often clip errors that were not present in the original design mockup.
Complete the journey with keyboard and representative assistive technology. An automated report can support the review, but it cannot replace listening to the error announcement and following its recovery path.
Verify the final promise
Check whether the confirmation describes a sent request, a server-saved draft or a local download accurately. A reference number should correspond to a real record in the intended system.
Review direct navigation, refresh and browser Back across multi-step flows. Preserve earlier answers where the process permits and make any deliberate expiry understandable.
Record findings as blocked tasks with reproducing steps. “Form looks accessible” is not a useful approval statement. Evidence that a user can locate two errors, correct them and receive the intended result is.
Primary sources
W3C WAI: user notificationsW3C WAI: target sizeReferences checked 11 September 2026.