A contact form is not finished because its button can be clicked. Check the whole task: understand the fields, correct an error, submit a message, and confirm that the intended recipient can find it.

Make the fields understandable

Use a visible, descriptive label for each input and check that it is associated with the control. W3C's form guidance explains those label relationships. A developer should inspect the markup as well as the appearance. Labeling Controls

Review the form with a simple example request. Can a visitor tell which fields are required, what information belongs in them, and what not to include? Remove unnecessary requests for sensitive information rather than adding a vague assurance below the form.

Make failures actionable

W3C recommends clear success and error feedback, including an explanation of the affected field and how to correct it. Test an empty required field and an invalid entry intentionally. User Notification

Check that you can locate the error using a keyboard and that the wording describes the actual problem. An error such as 'invalid submission' leaves the visitor without a useful next step. Ask the developer to preserve the visitor's legitimate entries when correcting another field.

Verify the receiving end

With the site owner's permission, submit a clearly labeled test using an owner-controlled recipient. Record the submission time and check the receiving system. A displayed confirmation alone is not the evidence you need for an end-to-end delivery check.

If delivery fails, preserve the test details and investigate the form handler and mail service separately. Do not repeatedly submit customer information or publish diagnostic logs containing messages.

These checks are a practical review, not a complete accessibility, privacy, or security certification. Use a fuller assessment for those requirements.

Sources

  1. Labeling Controls — W3C Web Accessibility Initiative
  2. User Notification — W3C Web Accessibility Initiative