An accessible form needs to work when someone enters information, makes a mistake, finds the problem, and tries again. The initial layout is only one state. Testing labels without testing validation can miss the point where a user loses the ability to continue.
Use this guide to plan a manual review of a contact form, booking flow, checkout, or account settings screen. It focuses on labels, instructions, errors, and recovery. Combine it with the keyboard testing checklist and the other methods agreed in your audit scope.
List the states the form can enter
Start with the task the form supports and the information needed to complete it. Record the URL, product version, account role, language, browser, viewport, and assistive technology used for the review. Use synthetic data appropriate for the test environment.
For a fictional appointment form, plan an empty submission, an invalid contact detail, a missing appointment choice, a successful correction, and the final confirmation. If a response comes from the server, test that response as well as any immediate validation in the browser.
| State | Question to answer | Evidence to keep |
|---|---|---|
| Initial form | Can the user identify what each control asks for? | Labels, instructions, control names, and environment |
| Incomplete submission | Can the user discover which information is missing? | Submitted test values and resulting messages |
| Invalid value | Is the problem described and a correction explained? | Field, rejected value, message, and reproduction steps |
| Corrected submission | Can the user continue without losing their place? | Navigation, changed messages, and retained information |
| Confirmation | Can the user tell the task has finished? | Final page or status message and observed presentation |
If you cannot trigger a planned state, keep it in the coverage record with the reason and owner. An unavailable server response is a testing gap that needs follow-up.
Check the label and the accessible name
Inspect the visible cue for every input, including optional fields, checkboxes, radio buttons, and custom controls. Then inspect the name exposed to assistive technology and compare it with what a user sees.
WAI's guidance on labeling controls describes explicit and implicit label associations and other naming mechanisms. For an explicit HTML label, the label's for value must match the input's id. A label placed near a field is not evidence that the association exists in the code.
Where a control has a visible text label, Success Criterion 2.5.3, Label in Name, requires its accessible name to contain that visible text. This matters for people who use the words on screen to operate controls with speech input. The name may include additional context; it need not always be an exact copy of the label.
As a practical check, focus each input during the screen reader pass and note its announced name. Investigate empty names, names that describe another field, and names that conflict with the visible instruction. Treat placeholder text as a hint and check what information remains available after the person enters a value.
Review instructions and related groups
Success Criterion 3.3.2, Labels or Instructions, addresses the information provided when content accepts user input. Programmatic names and relationships are separate considerations, so an accessible name alone does not settle whether the instructions are sufficient for users.
Before entering data, ask whether a person can determine which fields are required, what an unfamiliar format means, and what choosing an option will do. Use an example format when it resolves real ambiguity. Keep the instruction close enough to the relevant question that the relationship is clear during the review.
Check groups as well as individual choices. A pair of radio options reading “Morning” and “Afternoon” needs the context of the question they answer. WAI's grouping controls tutorial describes fieldset and legend for associating related HTML controls, along with other grouping approaches. Inspect the resulting experience instead of assuming that any one attribute proves the group is understandable.
Trigger errors and inspect their meaning
Submit the agreed invalid and incomplete examples. Write down the exact input that produced each response so another reviewer can reach the same state.
Success Criterion 3.3.1, Error Identification, requires an automatically detected input error to identify the affected item and describe the error in text. A red border alone does not communicate that description. The criterion does not prescribe one universal arrangement for inline messages, summaries, or dialogs.
Then examine whether the response helps the user recover. Success Criterion 3.3.3, Error Suggestion, requires known correction suggestions unless they would jeopardize the security or purpose of the content. Keep that exception in mind when reviewing responses involving account access or sensitive information.
For the fictional appointment form, “Contact number is incomplete; enter the remaining digits” is more actionable than “Invalid input,” assuming that description matches the actual input rules. This is an illustrative message-writing example, not a prescribed format or a judgment about a particular live service.
Test discovery and announcements separately
A message can be written clearly and still be difficult to find. Inspect where focus remains after submission, how the user reaches the response, and how a screen reader presents it in the tested setup.
WAI's form notification guidance discusses overall and inline feedback. An error summary can identify the affected questions and offer links back to their controls. If the form uses this approach, test the links and their destinations instead of recording only that the summary exists.
For a message that appears without changing context or receiving focus, consider Success Criterion 4.1.3, Status Messages. It concerns programmatically available status information that assistive technology can present without moving focus to the message. It does not require focus to jump to every update, and it does not cover every piece of newly inserted content.
Observe the actual announcement when a response appears. Record the browser and screen reader combination, what was announced, and whether it arrived at a useful point in the task. The presence of a live-region attribute is implementation evidence; the interaction test shows what happened in that environment.
Correct the data and complete the process
Return to each affected control, change the information, and submit again. Check whether the old error still appears, whether the new result is understandable, and whether the user can reach confirmation. Include any additional step that the form opens after correction.
As practical usability checks, note unnecessary loss of previously entered information, repeated validation that contradicts the displayed instruction, and confirmation text that leaves the outcome ambiguous. Map a formal WCAG finding only after assessing the actual behavior and applicable requirement. Useful observations can also be reported as improvement recommendations when they do not establish a criterion failure.
If authentication is part of the task, extend the plan with the WCAG 2.2 accessible authentication checklist. A form's labels and error behavior are only part of evaluating the sign-in process.
Make the finding and retest specific
A useful finding describes the user's task, the submitted test data, the resulting state, the affected field, and the observed barrier. Attach the relevant criterion with reasoning, the environment, the proposed correction, and the responsible owner.
After remediation, repeat the same error state and continue through the task. If the validation logic or shared form component changed, inspect the other scoped forms that rely on it. Use the accessibility evidence handoff guide to connect these observations to the next review.
OnChange's preserved page evidence can help a team inspect changed markup, styles, and presentation. It does not establish whether a runtime error was announced or whether someone completed the form using assistive technology. Keep the manual observation with the relevant release evidence.
Sources and scope of this checklist
The linked W3C WAI tutorials and WCAG Understanding pages were checked on 6 October 2026. They support the requirements and implementation guidance described here. The fictional example and test matrix are practical suggestions. This checklist concentrates on form interaction and should be used within the wider audit scope, rather than treated as a complete accessibility evaluation.