What the reader needs
If a form needs a particular format, explain it beside the field before submission. Dates, phone numbers and company identifiers can be interpreted differently across markets. Prefer flexible inputs where the service can support them, and show an example when a restriction is genuinely necessary. Mark optional information explicitly where it might otherwise seem compulsory. The instruction should tell the visitor how to succeed, not merely warn that an invalid entry will be rejected.
How to review it
Test the form using examples from the audiences you actually serve. Check international names, different phone formats and longer company names. When an input fails, decide whether the restriction reflects a real operational requirement or an unnecessary implementation assumption. Have the team document any unavoidable limitations and provide a workable contact alternative. Review instructions after validation rules change, because correct guidance can become misleading if the underlying form is updated without the copy.
Hypothetical example
A company’s enquiry form accepts only one phone-number format despite serving several markets. The team broadens the input handling and adds a clear example. Visitors who prefer email can leave the phone field blank because the form now marks it as optional.
Make it practical.
Use this checklist as you read. Checks are not stored.References & further reading
Further reading: W3C WAI: Form instructions ↗Published by Tap Tap Go. Product availability and eligibility vary by programme and market. About our stories.
