{"id":992425,"date":"2026-06-26T06:55:43","date_gmt":"2026-06-26T06:55:43","guid":{"rendered":"https:\/\/ifdb.io\/accessible-error-messages-when-the-form-simply-wont-submit\/"},"modified":"2026-10-12T09:34:10","modified_gmt":"2026-10-12T09:34:10","slug":"accessible-error-messages-when-the-form-simply-wont-submit","status":"publish","type":"post","link":"https:\/\/ifdb.io\/en\/accessible-error-messages-when-the-form-simply-wont-submit\/","title":{"rendered":"Accessible error messages: when the form simply won\u2019t submit"},"content":{"rendered":"\n

An accessible error message determines whether a person can submit a form \u2013 or is left sitting there at a loss because it \u2018just doesn\u2019t work\u2019. After all, a field with a red border is invisible to a blind user. If the error message is only visual, they\u2019ll click \u2018Submit\u2019, nothing will happen, and they won\u2019t know why. In this guide, I\u2019ll 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. <\/p>\n\n

What is an accessible error message?<\/h3>\n\n

An accessible error message clearly explains to every user what has gone wrong \u2013 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. <\/p>\n\n

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. <\/p>\n\n

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 \u2013 it is often the final hurdle before the finish line. <\/p>\n\n

The biggest problem: the silent error message<\/h3>\n\n

The most common and most serious barrier is the \u2018silent error message\u2019. This occurs when an error is visible but is never reported to the screen reader. A blind person fills in the form, clicks \u2018Submit\u2019 \u2013 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. <\/p>\n\n

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. <\/p>\n\n

This is exactly where our in-depth \u2018Access Ready\u2019<\/a> audit comes in. We work with real users of assistive technology to check whether an error message actually gets through \u2013 not just whether it\u2019s present in the code. After all, being present and being audible are two different things. <\/p>\n\n

Who relies on good error messages<\/h3>\n\n

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. <\/p>\n\n

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. <\/p>\n\n

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 \u2013 for all users, not just those with disabilities. <\/p>\n\n

The three functions of every error message<\/h3>\n\n

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. <\/p>\n\n

Task<\/th>WCAG criteria<\/th>Level<\/th><\/tr><\/thead>
Identify errors in the text<\/td>3.3.1 Fault detection<\/td>A<\/td><\/tr>
Suggest a solution<\/td>3.3.3 Error suggestion<\/td>AA<\/td><\/tr>
Audible error notification<\/td>4.1.3 Status messages<\/td>AA<\/td><\/tr><\/tbody><\/table><\/figure>\n\n

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 \u2013 but together, they make the difference between frustration and success. <\/p>\n\n

Which field? In text, not just in colour <\/h3>\n\n

An error message must state which field is affected \u2013 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. <\/p>\n\n

The relevant criterion is clear. Success Criterion 1.4.1 \u2018Use of Colour\u2019 (Level A) prohibits conveying information through colour alone. A red border is therefore never sufficient. <\/p>\n\n

The solution is simple. Always combine the colour with text and, ideally, a symbol. That way, every user will recognise the error \u2013 whether through the colour, the symbol or the text. I explain this in more detail in the guide to colours and contrasts<\/a>. This ensures the warning remains clear even for those who cannot perceive colours at all. <\/p>\n\n

What\u2019s incorrect \u2014 and how to fix it<\/h3>\n\n

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, \u2018Error Suggestions\u2019 (Level AA), requires. A message such as \u2018Invalid input\u2019 or simply \u2018Error\u2019 does not meet this requirement, as it leaves the user in the dark. <\/p>\n\n

Helpful messages are specific. Instead of \u2018Invalid input\u2019, it is better to say: \u2018The email address must contain an @\u2019. Instead of \u2018Error in the date field\u2019, it is better to say: \u2018Please enter a date in the format DD.MM.YYYY\u2019. This way, the user knows immediately what to do.<\/p>\n\n

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\u2019t done anything wrong; they just need a little guidance. <\/p>\n\n

Making the error message audible<\/h3>\n\n

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\"<\/code> to mark the field containing the error, and use aria-describedby<\/code> to link the error message to the input field via its ID. <\/p>\n\n

The result is audible. When the user clicks on the field, the screen reader announces the label, the \u2018invalid\u2019 prompt and the error message. This creates a complete, spoken response from three components \u2013 for example: <\/code> with an associated <\/span><\/code>. The field\u2019s label must also be correctly linked for this to work; otherwise, the beginning of the announcement will be missing. <\/p>\n\n

Dynamic errors require a more sophisticated approach. If a message only appears after submission without the page reloading, use role=\"alert\"<\/code> for immediate, interrupting messages or a section with aria-live=\"polite\"<\/code>. The newer attribute aria-errormessage<\/code> would be a more elegant solution, but is not yet widely supported \u2013 which is why aria-describedby<\/code> remains the safest option for the time being. Find out more in the guide to ARIA in web applications<\/a>. The key thing is to implement one variant consistently and correctly. <\/p>\n\n

Example: a good error message and a bad one<\/h3>\n\n

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. <\/p>\n\n

The poor option relies solely on visual cues. The field is given a red border, and the word \u2018Error\u2019 appears next to it. For a screen reader, neither of these has any meaning: no link, no specific indication, no audible signal. <\/p>\n\n

The best option combines all the elements. The field is labelled aria-invalid=\"true\"<\/code>, the message is linked via aria-describedby<\/code> and marked as role=\"alert\"<\/code>, and the text clearly states: \u201cThe email address must contain an @.\u201d An icon complements the colour. This way, every user \u2013 whether sighted or not \u2013 knows immediately what to do. <\/p>\n\n

Putting the focus in the right place<\/h3>\n\n

If a form is submitted with errors, the focus determines what happens next. If the focus remains on the \u2018Submit\u2019 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. <\/p>\n\n

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. <\/p>\n\n

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<\/a>. <\/p>\n\n

The error summary for long forms<\/h3>\n\n

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. <\/p>\n\n

The process is clearly defined. Once submitted, the focus moves to this overview, which is labelled role=\"alert\"<\/code> 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. <\/p>\n\n

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. <\/p>\n\n

Preventing errors before they occur<\/h3>\n\n

The best error message is the one that isn\u2019t needed at all. That is why accessibility starts here, with prevention. State what is expected before the user enters anything \u2013 for example, \u2018Password: at least 8 characters, including one number\u2019. 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. <\/p>\n\n

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. <\/p>\n\n

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. <\/p>\n\n

Clearly mark mandatory fields<\/h3>\n\n

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 \u2018Labels or Instructions\u2019 (Level A) requires. <\/p>\n\n

A common stumbling block is the asterisk. A single \u201c*\u201d is a familiar convention for sighted users, but for a screen reader it is often simply \u201cstar\u201d \u2013 with no clear meaning. You should therefore add the word \u201cmandatory field\u201d after the asterisk or mark the field technically with aria-required=\"true\"<\/code>. This ensures that screen reader users can reliably identify which details are mandatory. <\/p>\n\n

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 \u2013 and is less likely to make a mistake from the outset. <\/p>\n\n

Success needs to be reported too<\/h3>\n\n

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 \u2018Your form has been successfully submitted\u2019 must therefore also be audible. <\/p>\n\n

Technically, this works in a similar way to error messages. A section containing role=\"status\"<\/code> or aria-live=\"polite\"<\/code> ensures that the success message is displayed without abruptly interrupting the user. This is precisely what success criterion 4.1.3, \u2018Status Messages\u2019, requires. <\/p>\n\n

A silent confirmation can be unsettling. If the confirmation is inaudible, the user won\u2019t know whether they need to resend. You should therefore ensure that every important status change \u2013 whether successful or an error \u2013 is also signalled audibly. Only then can an interaction be considered complete in a way that is clear to everyone. <\/p>\n\n

New in WCAG 2.2: fewer barriers in forms<\/h3>\n\n

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. <\/p>\n\n

The first concerns repetition. Success criterion 3.3.7, \u2018Redundant input\u2019 (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. <\/p>\n\n

The second point concerns the login process. Success Criterion 3.3.8, \u2018Accessible Authentication (Level AA)\u2019, 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<\/a>. <\/p>\n\n

The test with your eyes closed<\/h3>\n\n

You can carry out the most important test yourself straight away. It costs nothing and reliably detects the silent error message. <\/p>\n\n

A practical exercise \u2013 the screen reader test<\/strong>: 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\u2019s an error? Can you hear which field is affected and what needs to be done? Move to that field \u2013 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\u2019ve found the most common barrier. This is exactly how a blind person experiences your form every day. <\/p>\n\n

Common mistakes in error messages<\/h3>\n\n

The same patterns recur time and again across many audits. These are the eight I see most frequently \u2013 and they can all be rectified: <\/p>\n\n