An accessible error message determines whether a person can submit a form – or is left sitting there at a loss because it ‘just doesn’t work’. After all, a field with a red border is invisible to a blind user. If the error message is only visual, they’ll click ‘Submit’, nothing will happen, and they won’t know why. In this guide, I’ll show you, based on practical audit experience, the three key functions every error message must fulfil, which WCAG criteria apply, how to link errors to the relevant field correctly from a technical perspective and make them audible, and how you can test all of this yourself in five minutes.
What is an accessible error message?
An accessible error message clearly explains to every user what has gone wrong – regardless of the assistive technology they use. If a user makes an input error, such as leaving a required field blank or using the wrong format, the system must do three things. It must identify the error, explain it and report it to the assistive technology.
This is underpinned by several WCAG criteria. Success Criterion 3.3.1 Error Detection (Level A) requires that an error be detectable in text form. Criterion 3.3.3 Error Suggestions (Level AA) additionally requires guidance on how to rectify it.
What matters is the reasoning behind it. An error message that only works for sighted mouse users is not a complete error message. After all, it is precisely in forms that it is decided whether a person can complete an order, submit an application or get in touch. That is why the error message is far more than just a detail – it is often the final hurdle before the finish line.
The biggest problem: the silent error message
The most common and most serious barrier is the ‘silent error message’. This occurs when an error is visible but is never reported to the screen reader. A blind person fills in the form, clicks ‘Submit’ – and hears nothing. The field is highlighted in red; there may even be text next to it, but they are unaware of any of this. They simply have no way of knowing that anything has gone wrong at all.
The result is confusion. The user presses the button again, checks their entries, and eventually gives up. From their point of view, the form is simply broken. Yet the solution could have been achieved with just a few lines of code. And that is precisely what makes this barrier so frustrating: it is easy to fix, yet it constantly goes unnoticed.
This is exactly where our in-depth ‘Access Ready’ audit comes in. We work with real users of assistive technology to check whether an error message actually gets through – not just whether it’s present in the code. After all, being present and being audible are two different things.
Who relies on good error messages
Clear error messages benefit far more people than just blind users. This is because a colour-coded message is also ineffective for the approximately nine per cent of men with red-green colour blindness. And a vague message can be overwhelming for people with cognitive impairments, as well as for learners whose first language is not German.
The method of operation also plays a part. Anyone filling in a form using only the keyboard needs the focus to be in the right place in order to spot the error in the first place. Good error messages therefore help a whole range of people at the same time. What is essential for blind users makes the process easier for everyone else.
On top of that, there is a very tangible business reason. Every form that freezes when an error occurs means a lost contact, an abandoned order or an application that is never submitted. Better error messages therefore directly reduce the abandonment rate – for all users, not just those with disabilities.
The three functions of every error message
A good error message always fulfils the same three functions. It specifies which field is affected, explains what is wrong with it, and announces this audibly to assistive technology. Each function corresponds to a separate WCAG criterion.
| Task | WCAG criteria | Level |
|---|---|---|
| Identify errors in the text | 3.3.1 Fault detection | A |
| Suggest a solution | 3.3.3 Error suggestion | AA |
| Audible error notification | 4.1.3 Status messages | AA |
These three elements are interlinked. If any one of them is missing, the message will have no effect on some users. The following sections explain exactly what each task entails. None of them is particularly time-consuming – but together, they make the difference between frustration and success.
Which field? In text, not just in colour
An error message must state which field is affected – in text form. After all, a field with a red border alone is of no help to anyone who cannot see the colour. This affects blind people as well as the approximately nine per cent of men with red-green colour blindness. Both groups need a notification that works regardless of the colour.
The relevant criterion is clear. Success Criterion 1.4.1 ‘Use of Colour’ (Level A) prohibits conveying information through colour alone. A red border is therefore never sufficient.
The solution is simple. Always combine the colour with text and, ideally, a symbol. That way, every user will recognise the error – whether through the colour, the symbol or the text. I explain this in more detail in the guide to colours and contrasts. This ensures the warning remains clear even for those who cannot perceive colours at all.
What’s incorrect — and how to fix it
An error message should not only indicate that something is wrong, but also specify what is wrong. This is precisely what success criterion 3.3.3, ‘Error Suggestions’ (Level AA), requires. A message such as ‘Invalid input’ or simply ‘Error’ does not meet this requirement, as it leaves the user in the dark.
Helpful messages are specific. Instead of ‘Invalid input’, it is better to say: ‘The email address must contain an @’. Instead of ‘Error in the date field’, it is better to say: ‘Please enter a date in the format DD.MM.YYYY’. This way, the user knows immediately what to do.
The difference is enormous. A vague message leaves the user guessing, whilst a specific one leads straight to the solution. You should therefore word every error message in such a way that it clearly states the next step. And keep the tone friendly: the user hasn’t done anything wrong; they just need a little guidance.
Making the error message audible
For a screen reader to read out an error message, it must be linked correctly from a technical point of view. Two ARIA attributes ensure this. Use aria-invalid="true" to mark the field containing the error, and use aria-describedby to link the error message to the input field via its ID.
The result is audible. When the user clicks on the field, the screen reader announces the label, the ‘invalid’ prompt and the error message. This creates a complete, spoken response from three components – for example: with an associated . The field’s label must also be correctly linked for this to work; otherwise, the beginning of the announcement will be missing.
Dynamic errors require a more sophisticated approach. If a message only appears after submission without the page reloading, use role="alert" for immediate, interrupting messages or a section with aria-live="polite". The newer attribute aria-errormessage would be a more elegant solution, but is not yet widely supported – which is why aria-describedby remains the safest option for the time being. Find out more in the guide to ARIA in web applications. The key thing is to implement one variant consistently and correctly.
Example: a good error message and a bad one
The difference between a poor and a good error message can be illustrated with an example. Both respond to the same incorrect email entry, but only one of them is accessible. In the code, there are often only a few attributes to distinguish between the two versions.
The poor option relies solely on visual cues. The field is given a red border, and the word ‘Error’ appears next to it. For a screen reader, neither of these has any meaning: no link, no specific indication, no audible signal.
The best option combines all the elements. The field is labelled aria-invalid="true", the message is linked via aria-describedby and marked as role="alert", and the text clearly states: “The email address must contain an @.” An icon complements the colour. This way, every user – whether sighted or not – knows immediately what to do.
Putting the focus in the right place
If a form is submitted with errors, the focus determines what happens next. If the focus remains on the ‘Submit’ button, a screen reader user will often not even notice the error. You should therefore place the focus specifically on the first field containing an error or on an error summary.
The tried-and-tested sequence is: first notify, then focus. First, a status message indicates that there are errors. The focus then jumps to the point where the correction begins. This way, the user knows immediately that they need to take action and where.
In practice, this step is most often overlooked. Yet it is crucial for keyboard usability. I go into more detail on how to control the focus effectively in the guide to keyboard navigation.
The error summary for long forms
For long forms, it is worth including an additional error summary. This appears at the very top of the form and lists all errors at a glance. Ideally, each entry is a link that takes the user directly to the relevant field.
The process is clearly defined. Once submitted, the focus moves to this overview, which is labelled role="alert" and is therefore read out immediately. This allows the user to see the full extent of the errors, rather than having to navigate through them one by one.
It is best to combine the two. The summary at the top provides an overview, whilst the individual message in the field gives specific guidance on the page itself. This dual approach saves users a great deal of time searching, particularly with multi-page forms. It is important to state the number of errors so that the user can immediately gauge the scale of the issue.
Preventing errors before they occur
The best error message is the one that isn’t needed at all. That is why accessibility starts here, with prevention. State what is expected before the user enters anything – for example, ‘Password: at least 8 characters, including one number’. This is also required by Success Criterion 3.3.2 Labels or Instructions (Level A). Use visible labelling for these prompts, not just a placeholder, as this disappears when you start typing.
Equally important is how the form handles user input. If you make a mistake, never delete the fields that have been filled in correctly; instead, simply highlight those that need correcting. Nothing is more frustrating than having to start a half-completed form all over again.
Timing is also important. It makes sense to validate an entry when the user leaves the field or when the form is submitted, rather than after every single keystroke. For transactions with legal or financial implications, section 3.3.4 on error prevention also requires a means of checking or correcting the entry before it is finally submitted.
Clearly mark mandatory fields
Many errors arise simply because it was unclear which fields needed to be completed. That is why good forms must clearly indicate which fields are mandatory. This is precisely what Success Criterion 3.3.2 ‘Labels or Instructions’ (Level A) requires.
A common stumbling block is the asterisk. A single “*” is a familiar convention for sighted users, but for a screen reader it is often simply “star” – with no clear meaning. You should therefore add the word “mandatory field” after the asterisk or mark the field technically with aria-required="true". This ensures that screen reader users can reliably identify which details are mandatory.
The combination is the most straightforward approach. A visible marker in the text, an explanatory caption and the technical markup all work together. This way, every user knows right from the start what is important – and is less likely to make a mistake from the outset.
Success needs to be reported too
It is not only errors that require feedback, but also success. After all, once a form has been submitted, a blind user will ask themselves the same question: Did it work? A message such as ‘Your form has been successfully submitted’ must therefore also be audible.
Technically, this works in a similar way to error messages. A section containing role="status" or aria-live="polite" ensures that the success message is displayed without abruptly interrupting the user. This is precisely what success criterion 4.1.3, ‘Status Messages’, requires.
A silent confirmation can be unsettling. If the confirmation is inaudible, the user won’t know whether they need to resend. You should therefore ensure that every important status change – whether successful or an error – is also signalled audibly. Only then can an interaction be considered complete in a way that is clear to everyone.
New in WCAG 2.2: fewer barriers in forms
Version 2.2 of the WCAG has introduced two new criteria that make forms significantly easier to use. Both are designed to prevent unnecessary obstacles before errors can even arise. This brings the concept of error prevention even more to the fore.
The first concerns repetition. Success criterion 3.3.7, ‘Redundant input’ (Level A), requires that users should not have to re-enter information within a single transaction. An address that has already been entered should therefore be carried over, rather than being requested a second time.
The second point concerns the login process. Success Criterion 3.3.8, ‘Accessible Authentication (Level AA)’, prohibits making the login process dependent solely on a memory test. You should therefore allow pasting from the clipboard and the use of password managers. I cover these changes in more detail in the guide to WCAG 2.2.
The test with your eyes closed
You can carry out the most important test yourself straight away. It costs nothing and reliably detects the silent error message.
A practical exercise – the screen reader test: Switch off your screen or close your eyes and complete your form using only a screen reader such as NVDA or VoiceOver. Deliberately submit it with errors: leave a required field blank, or enter an invalid email address. Now listen carefully. Do you even realise that there’s an error? Can you hear which field is affected and what needs to be done? Move to that field – is the message read out there? And does the success message play audibly when you fill in the form correctly? If you find yourself stuck at any point, you’ve found the most common barrier. This is exactly how a blind person experiences your form every day.
Common mistakes in error messages
The same patterns recur time and again across many audits. These are the eight I see most frequently – and they can all be rectified:
- Just colour: a red box with no text and no symb
- Vague messages such as ‘Error’ or ‘Invalid input’.
- A silent message that remains inaudible to the screen reader.
- No link through
aria-describedbyandaria-invalid. - The focus remains on the ‘Send’ button rather than on the error.
- The entries have been deleted, so the user must start again.t.
- A test every time you press a key, which constantly interrupts.
- A placeholder is the only label that disappears whilst you are typing.
One thing stands out here. Almost no errors arise from malicious intent. Rather, they arise because the form was tested using only a mouse and the eyes – and neither of these picks up on these problems. A single test using a screen reader uncovers most of them.
Frequently asked questions about accessible error messages
To round off, here are the questions I come across most frequently in my practice. The answers are brief and to the point.
Is a red border sufficient to indicate an error?
No. A border on its own contravenes 1.4.1 Use of colour. Always combine the colour with text and, ideally, a symbol.
How does a screen reader detect an error?
About the error in the code. Select the field marked aria-invalid="true" and link the message via aria-describedby. Dynamic errors are indicated by role="alert".
Where should the focus move to after a mistake?
On the first field containing an error or the error summary. If the focus remains on the ‘Send’ button, a screen reader user will often not notice the error. The sequence ‘report first, then focus’ has therefore proven effective.
How to make your error messages accessible
The process begins with measurable issues and ends with the perceived reality. The free Access Score provides a quick overview in a matter of minutes. It automatically identifies what can be measured: missing labels, colour-only coding or missing ARIA links.
However, it is only when a message is actually used that it becomes clear whether it has been understood. Can a blind person hear what has gone wrong? Can they find the correct field? Do they understand what to do? A scanner alone cannot assess this. With Access Ready, we test your forms using real users of assistive technology and issue a legally compliant certificate.
| Approach | Checks code | Checks audibility | Evidence |
|---|---|---|---|
| Free scanner | measurable defects | no | no |
| Overlay-Widget | Covers up, does not fix | no | no |
| Access Ready (ifdb) | Code and Experience | yes | yes |
The difference lies in our approach. Others check whether a message is included in the code and leave the rest to you. We check whether a person actually hears and understands it. This turns ‘the error is right there’ into a proven ‘everyone knows what to do’. And a form that people struggle with becomes one that everyone completes right to the end.
Want to know what digital accessibility means for your organisation? In 30 minutes, we will go through your requirements and the most sensible next steps with you.
