Plain Language Error Messages with Actionable Guidance
Technical or ambiguous error messages create anxiety and confusion for users with cognitive challenges, stroke survivors, or low digital literacy. The plain-language error display component must retrieve messages from a centralised error message registry, ensuring all errors are reviewed for readability. Each error message must state what happened, why it matters, and the single next step the user should take. Error messages must never use technical jargon, error codes, or passive constructions.
User Story
Acceptance Criteria
- Given I submit a form with a missing required field, When the error appears, Then the message names the specific field in plain language (e.g., 'Please enter the date of the activity') rather than a generic 'Validation error'
- Given a network error occurs during submission, When the error is displayed, Then the message explains in simple terms what to do next (e.g., 'Your internet connection dropped. Please check your connection and tap Try Again')
- Given any error message is shown, When I read it, Then it contains no technical codes, HTTP status numbers, or developer terminology
- Given the error message registry is populated, When a new error type is added to the system, Then it must include a plain-language version before being deployed
- Given an error is displayed, When I tap the suggested action button, Then the system performs that action immediately (retry, navigate back, open settings)
- Given I have corrected the error and resubmitted, When the submission succeeds, Then the error message is dismissed and a positive confirmation replaces it
Business Value
Users with cognitive challenges abandon tasks when they encounter confusing error messages, leading to underreporting and frustration. Plain language errors reduce support burden for coordinators and increase successful task completion rates. This directly supports WCAG 2.2 AA compliance requirements, which are contractually expected by all partner organisations.