Contact forms: check labels, errors and keyboard completion

Start with the visitor's task

Choose one real form and write what a visitor is trying to accomplish: asking about an appointment, requesting a quote or reporting a problem. Remove fields that have no clear purpose for that task. Then inspect the form in its actual published context, including any embedded provider interface, rather than judging a screenshot of the empty design.

W3C's form tutorial recommends associating a label with its control and explains the benefit for assistive technology. A visible caption next to a box is not enough to prove that association exists. For ordinary HTML controls, the explicit label relationship uses a matching for attribute and control id. [1]

Check names while the fields contain text

Click or focus each field and type a harmless test value. Its purpose should remain understandable after the placeholder disappears. Inspect whether required fields are identified before submission and whether an unfamiliar format has an instruction nearby. A short form still needs these cues.

For a builder-managed form, use its supported label and instruction settings first. If the platform does not expose a necessary relationship, document the limitation and ask for a supported fix. Avoid layering visually hidden custom text without checking the resulting accessible name; duplicate or contradictory labels can make the form harder to understand.

Worked example: a quote request that cannot be corrected

Imagine a fictional form with Name, Email and Project fields. A visitor enters a name and project description but mistypes the email address. After submission the form shows only a red border and clears every field. In this invented review, two acceptance cases fail: the correction is not explained, and useful entered information is lost.

The proposed repair is a specific email error, an understandable association with the field and preservation of the other safe values. Test the corrected path again from the beginning. Do not mark the issue resolved because a designer changed the color. The evidence should show a visitor can identify and fix the problem.

Review keyboard and error paths

Move through the form using the keyboard. Record the order of controls, whether focus is visible, whether the submit button can be activated and whether any overlay traps navigation. Then submit one deliberate missing-field case and one malformed-value case. Use synthetic values and an authorized destination so the review does not create unwanted messages.

W3C's notification tutorial discusses feedback for successful submission and errors, including ways to identify errors and help users navigate them. Use those techniques as a design reference; the best mechanism depends on whether your form updates in place or navigates to a new page. [2]

Separate a usable form from a complete delivery chain

After correcting the error, submit one authorized valid test. Read the acknowledgement and verify that it accurately describes the state. Record actual inbox receipt using the separate delivery checklist for your provider. A clear acknowledgement can still accompany a delivery failure, while a delivered message can come from an unnecessarily difficult form.

Retain the browser and device, expected behavior, observation and issue owner in the worksheet. Include a small-screen pass and, where available, an assistive-technology review by someone familiar with it. This research checklist is not an accessibility certification or a complete standards audit. It targets a bounded contact-form task and leaves broader page navigation, contrast, content and technology combinations for further review.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. W3C Web Accessibility Initiative: Labeling Controls Accessed 2026-09-14
2. W3C Web Accessibility Initiative: User Notification Accessed 2026-09-14