Practical working guide
How to make enquiry-form errors understandable and accessible
An accessible enquiry-form error identifies the affected field, explains how to fix the problem and lets the person continue without losing valid answers. Combine visible text with programmatic associations and keyboard access; a red border alone is not an adequate instruction.
Replace vague messages with repair instructions
| Failure | Details |
|---|---|
| Missing contact method | Unhelpful copy: Invalid form Useful instruction: Add an email address or phone number so we can reply. |
| File too large | Unhelpful copy: Upload failed Useful instruction: Choose a file within the stated size limit. |
| Network failure | Unhelpful copy: Something went wrong Useful instruction: Your enquiry was not confirmed. Keep this page open and try again. |
Sources: W3C WAI — Form notifications.
Test the whole recovery, not just the wording
W3C WAI describes clear error notifications and guidance for correcting mistakes. Use this acceptance record with the actual form, keyboard and a screen reader. The sample outcomes below are targets, not results of a test on your site.
- Submit with required fields empty: an error summary explains the problem and leads to the relevant fields.
- Correct one field: its error clears without erasing other answers or moving focus unexpectedly.
- Trigger a harmless server failure: no success confirmation appears, and retry does not create duplicate enquiries.
Keep an evidence row for each issue
Record the field, input, expected announcement, observed focus, preserved values and next action. For example, “attachment rejected; description retained; file input announced; customer can replace file” is actionable evidence. “Looks accessible” is not. Check errors in every published language and ensure the success state states what actually happened, without promising a response time you cannot meet.