TAP TAP GO
What the reader needs
A message saying “something went wrong” gives little help when a visitor has entered a detailed enquiry. Distinguish errors the person can correct from service failures they cannot fix. For an input issue, identify the affected field and explain the expected correction in plain language. For a service failure, preserve the person’s work where possible and provide a sensible retry or alternative contact route. Do not present an internal technical code as the only explanation.
How to review it
Test the unhappy paths deliberately: missing required information, an invalid reply address and an interrupted submission. Check that the error is visible and available to assistive technology, not communicated only through colour. Confirm whether previously entered information remains intact. Then test the successful submission to ensure the confirmation is equally clear. A form that handles mistakes respectfully is part of the publication’s credibility; readers should not have to guess whether their request was received.
Hypothetical example
A reader omits the reply address from an enquiry. Instead of clearing the whole form, the page points to the missing field and keeps the message intact. When the reader corrects it, a confirmation explains that the enquiry has been submitted and what response to expect.
Make it practical.
Use this checklist as you read. Checks are not stored.References & further reading
Further reading: W3C WAI: User notifications ↗Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.
