When a contact form changes, keep enough evidence to answer four questions later: what changed, who approved it, what was tested, and whether real submissions still reached the intended destination. A screenshot by itself is not enough. Preserve the old and new field definitions, delivery route, validation behavior, accessible interaction, test results, and rollback point without copying real customer messages into a change packet.
Capture the starting state
Before editing, record the page URL, form version or commit, active fields, required states, confirmation text, recipient or ticket queue, spam controls, retention rules, and any third-party service involved. Save a redacted screenshot and a machine-readable field list when the platform permits it. Identify who can change the form and who receives submissions. If a vendor-hosted component is used, record the vendor, account owner, plan dependency, and current export path.
Use invented test data. Do not place real names, addresses, phone numbers, private messages, API keys, or full submission bodies in screenshots or logs. The W3C forms tutorial advises asking only for information needed to complete the process. That principle belongs in the evidence record: for every field, note the business purpose and whether it is optional, required, or newly removed.
Describe the change as a testable statement
Write the reason and expected outcome in plain language. Examples include reducing abandonment by removing a field, routing sales questions to a ticket queue, adding a consent choice, or correcting an inaccessible error message. List the exact fields, labels, validation rules, notification addresses, webhook destinations, and confirmation messages affected. Distinguish a content edit from a routing or data-handling change because the latter can succeed visually while failing operationally.
Record the approval date, owner, planned release window, dependencies, and rollback method. If legal or privacy review is required, store the decision or link to its controlled location rather than claiming approval from silence. A useful record makes unknowns visible.
Prove accessibility and validation behavior
Test the complete path with keyboard navigation, visible focus, browser zoom, a screen reader where available, and both valid and invalid entries. Preserve expected and observed results for labels, instructions, required-field cues, error identification, correction, success notification, and timeout behavior. W3C's guidance emphasizes labels, instructions, validation, and understandable notifications, so the evidence should cover more than a successful click.
Security evidence should show that the server enforces field rules even if the browser also checks them. The OWASP Input Validation Cheat Sheet recommends server-side validation, field-specific acceptance rules, and bounded inputs. Record representative accepted and rejected cases, response codes, and the fact that sensitive values were excluded from logs. Do not preserve attack strings in broadly accessible documentation when a protected test report can reference them safely.
Verify delivery from end to end
A form is not proven by a success banner alone. Submit a uniquely identified test message, then confirm its appearance in the actual mailbox or ticket system without changing unrelated messages. Record the submission time, receipt time, destination, test identifier, and any automated reply. Check the failure path by using a safe staging control or documented simulator rather than deliberately breaking production.
If delivery crosses a webhook, automation, CRM, or spam filter, capture each handoff and its owner. Verify that retries do not create duplicates and that the user receives an honest response when downstream delivery fails. Record monitoring or alert coverage, but do not interpret the presence of a log entry as proof that the final recipient saw the message.
Keep a privacy-conscious release packet
The final packet should contain the change summary, before-and-after field map, approvals, redacted visual evidence, accessibility results, server-validation results, end-to-end receipt evidence, rollback instructions, and open issues. Include dates, environments, and tester names or roles. Store only the minimum submission data needed to establish the test and follow the site's retention policy.
After release, perform a short live check with invented data and monitor aggregate failure signals. Compare the live form to the approved field map, then close the change only after delivery and recovery are proven. A compact, redacted packet is stronger than a folder of unlabeled screenshots because it preserves the decision, the tested path, and the limits of what was actually verified.
Sources
- Forms Tutorial — World Wide Web Consortium Web Accessibility Initiative
- Input Validation Cheat Sheet — OWASP Foundation