Can customers fix a failed enquiry form without starting again?

Buy a complete recovery path

Imagine a customer requesting air-conditioner cleaning on a phone during a commute. They select a service and district but leave the contact email incomplete. If submission returns an empty form, they must reconstruct the request. For a home-services SME with a small improvement budget, the decision is whether to accept the revised form as usable after a mistake, not just whether the normal submission works. Use dummy enquiries in a test environment, with one staff member responsible for checking the receiving system.

Keep the existing short form if its controls and backend can support the changes. A replacement form service is an alternative when the current system cannot return useful errors, but allow for migration, data handling and staff routing work. A staffed telephone route can cover a temporary failure; it is not a substitute for fixing a form used outside opening hours. Ask for a bounded quotation covering error states, retained selections, receipt behaviour and the tests below before funding a wider redesign.

Specify the summary and field messages

W3C WAI recommends feedback for both successful and unsuccessful submissions, with an error list that identifies the field, explains the correction and links to its control. The proposed example below applies that guidance to an enquiry form requiring an email address and service district. These are editorial examples, not a live form or a claim of complete accessibility conformance.

The two-error count belongs only to this example. Real summaries must match the current errors and disappear when resolved.

Agree the field rules before polishing the words. An email typo, an unsupported service district and a temporary server failure need different responses. If a district is outside your coverage, explain that constraint and offer only an alternative your staff can actually provide. Do not label a network interruption as a customer mistake. Check that the English and Chinese labels used in the summary match the labels on the respective form, including any optional fields.

Keep useful entries within a stated boundary

For this proposed design, keep non-sensitive selections such as service type and district during correction in the current page. Let the customer edit them rather than silently resetting to a default. A language switch should preserve those same selections; test it explicitly instead of assuming a translated page shares state. This retention policy is a design choice for the example, not a mandate from the cited W3C page.

Treat names, phone numbers, exact addresses, access instructions and free-text descriptions separately. For a first enquiry, consider deferring the full address until staff arrange the visit. If contact details remain on the current page for correction, document that behaviour and clear them after confirmed success. Do not quietly add a browser draft that survives closing the page. If persistent drafts are necessary, scope their expiry, deletion and shared-device behaviour as additional work. Tell users when an attachment must be selected again.

Distinguish a receipt from an uncertain result

Only show a success receipt after the receiving system confirms the enquiry was accepted. For this example, the receipt displays the real enquiry reference, explains that an appointment is not yet booked and states the next step the team can deliver. A promised callback deadline needs an operational owner; omit it until agreed. An email acknowledgement can supplement the on-page receipt, but its delivery should not be the only way customers know their request exists.

Use these states only when the system can distinguish them. Add the real reference and an existing, staffed contact route; do not publish placeholder details.

A timeout may happen after the server has stored the enquiry. Ask the developer how a retry avoids creating a second job, and have staff test that case. Temporarily disabling the submit button while waiting helps prevent repeated clicks but does not by itself make retries safe. Keep the failure message visible with a usable next action; an endless spinner leaves both the customer and the coordinator guessing.

Run one recovery rehearsal before sign-off

Book a short acceptance session with the coordinator and developer. Start in English, then repeat independently in Traditional Chinese using the same task rather than comparing sentence lengths. Record the browser, device, result and owner of each defect. Approve the change only when the customer can correct the enquiry and staff can find one matching record. If a check fails, return that specific behaviour for correction instead of accepting a screenshot of a green success banner. No conversion uplift is assumed by this exercise.

1. Trigger the errors

   Choose a service, leave the district blank and enter an incomplete email. Submit using only the keyboard. Check that the summary appears and the valid service choice remains.

2. Follow the correction path

   Use Tab and Shift+Tab to reach each summary link, then Enter to activate it. Focus must be visible on the correct control. Correct both fields and confirm that stale errors clear.

3. Listen and switch language

   With a screen reader, check that the submission result and field correction are understandable without sight. Repeat with retained selections after switching language; also inspect narrow screens and zoom.

4. Verify delivery and recovery

   In the test environment, exercise normal receipt, confirmed failure and timeout after storage. Check retry behaviour and one receiving record, then verify the alternative contact route with staff.