Start with the visitor's task
Write what a visitor is trying to do: ask about an appointment, request a quote, report a problem. Remove any field that does not serve that task. Then check the form as published, including any embedded provider form, rather than a screenshot of the empty design.
The six checks
W3C's labeling tutorial says the label's for attribute must exactly match the control's id. It notes two benefits: browsers make the label a larger click target, and assistive technology can announce the right label for the field. A label can be hidden visually if it is still in the code, but W3C says other parts of forms should not be hidden. [1]
| Check | Passes when | Fails when |
|---|---|---|
| Label in code | Each field has a label whose for value matches the field's id | Text sits next to the box but is not connected to it |
| Label visible while typing | The field's purpose is clear after you start typing | The only hint was placeholder text that disappears |
| Error names the field | The message says which field and what to change | Only a red border or a generic Something went wrong |
| Focus on error | After submitting, focus moves to the first field with an error | The visitor has to hunt for the problem |
| Keyboard only | Tab reaches every field and the button, focus is visible, Enter or Space submits | A control cannot be reached or focus disappears |
| Success message | A clear message confirms the form was sent | The page reloads with no confirmation |
How to report errors
W3C's notification tutorial describes three places to tell people about errors: the main heading or page title (for example, including the word error and the number of errors), a list of errors at the top of the page before the form, and in-line messages next to each field, usually combining text with a visual cue. It recommends setting focus to the first input that has an error. [2]
Timing matters too. W3C notes instant feedback while typing can help, but for fields with a required format, such as dates, it makes more sense to check when the visitor leaves the field rather than on every keystroke. Success messages matter as much as errors because they confirm the task is done. [2]
Worked example: a quote form that cannot be corrected
Hypothetical: a form with Name, Email and Project fields. A visitor fills them in but mistypes the email. On submit, the email box turns red and every field is cleared. Two checks fail: the error does not say what is wrong, and the visitor loses the project description they wrote.
The repair: an in-line message such as Email address needs an @ sign, tied to the email field; focus moved to that field; the other entries kept. Then test the corrected path from the beginning. Changing the border colour is not a fix; the evidence should show a visitor can find and correct the problem.
Using a website builder's form
Use the builder's own label and instruction settings first. If it does not expose a needed label relationship, note the limitation and ask the vendor for a supported fix. Avoid adding hidden custom text without checking the result, because duplicate or contradictory labels can make the form harder to use.
Separate a usable form from a delivered message
After the form passes, submit one authorized valid test and confirm the message reached the intended inbox. A clear success message can still hide a delivery failure, and a delivered message can come from a form that is hard to use. Record browser, device, expected result and what happened.
This checklist covers one contact-form task. It is not an accessibility certification or full standards audit; page navigation, contrast and assistive-technology testing by an experienced user need their own review.
Inspect authentication for the missing form message — Automation Tools Compared — If a valid form submission produces a rejected or spam-folder notification, examine that sender's authentication and alignment using the received message or rejection evidence.
Questions before you decide
Is placeholder text enough as a label?
Treat it as no. W3C's labeling tutorial recommends a label element tied to the control with matching for and id values, so assistive technology can announce it and the label gives a larger click target. Placeholder text disappears once someone types.
Where should form error messages appear?
W3C's notification tutorial describes listing errors at the top of the page before the form, indicating errors in the heading or page title, and showing in-line messages next to fields, and suggests setting focus to the first field with an error.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- W3C Web Accessibility Initiative: Labeling Controls Accessed 29 Oct 2026
- W3C Web Accessibility Initiative: User Notification Accessed 29 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.