How do we validate validation? How do we prevent our error handling having errors?
What to do
Here’s a short version of what to do for high quality, accessible, validation.
- Show which fields have errors, with more than just colour
- Show an informative error message, programmatically associated with its field
- Manage focus on submit: to the first invalid field for short forms; to the heading of an error summary for longer forms
How to check
Find a form, then immediately submit it, without entering any data.
Some common forms:
- log in (often linked from the header)
- contact us (often in the header or footer)
- newsletter subscription (often in the footer)
- ecommerce flow (sometimes possible to checkout as guest)
- questionnaire or wizard flows
What to check
Here’s a short version of potential issues, with the relevant Success Criteria (SC) from WCAG. All them are considered High severity.
- Error show by colour alone. SC: 1.4.1 Use of Color (Level A).
- Add an icon or “Error: “ to the label
- No error message. SC: 3.3.1 Error Identification (Level A).
- Not a helpful error message. SC: 3.3.3 Error Suggestion (Level AA).
- Make it clear that something has gone wrong (don’t leave the user guessing whether everything is okay or not)
- State clearly and precisely the reason for the error (don’t make the user guess what went wrong)
- Avoid negative words if you can, don’t blame (no-one likes being told off or that it’s their fault)
- Don’t use jargon or error codes: express everything in the user’s vocabulary. (Most humans don’t speak developer)
- Constructive advice on how to fix the problem (Help them fix it)
- Not a programmatically associated error message. SC: 1.3.1 Info and Relationships (Level A).
- Add
aria-describedby="id-of-the-error-text"to the field - And
aria-invalid="true"on the field with an error
- Add
- Focus not managed on error. SC: 2.4.3 Focus Order (Level A).
- Manage focus on submit: to the first invalid field for short forms, to the heading of an error summary for longer forms