Building useful websites
Does your contact form actually deliver? A five-part check
A working Send button is only the beginning. Follow one harmless message to its destination, then check what a reader sees when something goes wrong.
Prepare one message you can recognize
Use a form you own or have permission to test. Choose a harmless marker such as “Contact check — blue notebook — 21 October”. Keep the text in a separate note. Do not use real customer information, passwords or payment details.
Decide where the message is supposed to end up: a private dashboard, an inbox, or both. If you cannot access that destination, arrange for its owner to confirm receipt. Seeing a confirmation in the browser checks only the visitor side of the journey.
1. Complete the journey on a phone
Pass condition: the intended recipient can find the complete message and the visitor receives a truthful confirmation. If storage and email notification are separate steps, verify each separately. “Saved to our inbox” does not establish that an email notification arrived.
- Start at the public homepage, find Contact and open the form. Do this without using a bookmarked direct link.
- Read the labels before typing. Check that the keyboard does not hide the active field or make the Send button unreachable.
- Submit the marker once. Record the page address, approximate time and exact confirmation text.
- Open the intended private destination and find the marker. Compare the complete message, including line breaks, with your note. If the site has several forms, check the recorded page or subject too.
2. Make one correctable mistake
On a preview or test version, submit an empty required field, then try a deliberately invalid value if the form requires a format. Avoid sending batches of errors to a public service.
W3C’s forms guidance recommends clear feedback about success or failure and instructions that help people correct an error. Apply that advice concretely: “Enter an email address so we can reply” is more useful than “Invalid input”. A red border alone does not explain what to fix.
Correct the field and continue. As an editorial acceptance check, require that the other text stays available: readers should not have to reconstruct a long message after fixing one field.
3. Interrupt the connection without losing the draft
Use the test version. After the form has loaded, disconnect the test device or put the browser’s network tools into offline mode. Enter a fresh marker and press Send. Restore the connection only after observing the result.
Look for three things: the form stops saying “Sending”; the text remains available to copy or edit; and the message explains that delivery could not be confirmed. Do not display a success message merely because a button was pressed.
A connection can fail after a server has saved a message but before the confirmation reaches the browser. Treat that outcome as uncertain. Check the recipient’s inbox before manually resubmitting the same test. A duplicate notice should tell the reader whether the previous message was already received.
4. Test the response, not just the field
Use Tab and Shift+Tab to reach the fields and button. Follow the visible focus indicator. Submit on the test version and check whether you can find the result without searching the whole page.
For messages inserted without moving focus, W3C’s status-message guidance explains that the result must be available to assistive technology through appropriate roles or properties. A developer can check the status region; a screen-reader test checks what is actually announced. A browser screenshot cannot establish that announcement.
If scripts are required, disable them and reload once. The page should explain how to proceed when the form is unavailable. An alternative contact method is useful only if someone actually monitors it.
5. Keep a small acceptance record
For a fictional community workshop, the record might say: “Phone: message saved once; inbox: marker found; offline: draft preserved; keyboard: submit reachable; screen reader: not checked.” This is a worked example, not a report from a real workshop.
Repeat the relevant checks after changing the form, its recipient address or its delivery service. This checklist is a practical functional check, not a full accessibility, security or email-deliverability audit.
- Address and date tested; phone or browser used.
- Harmless marker; confirmation shown; destination in which it was found.
- Empty-field result; offline result; whether the draft survived.
- Keyboard result; screen-reader result, or explicitly “not checked”.
- Any defect, who will fix it, and the next retest.