Support for aria-errormessage is getting better, but still not there yet

Number of words: 893.

(Loaded 2326 times)

I like the idea behind aria-errormessage and hope it will soon get enough support to make error messages more accessible and establish itself as best practice. NVDA support is coming soon, but beware potential iOS bug and lack of TalkBack support…

I have seen aria-errormessage used in production a bit, and I wished it would replace the existing “hack” when we use aria-describedby for error messages, but after I’ve checked for it’s support, it was not ready yet. It worked in some screen-reader and browser combinations, but NVDA, for example, didn’t support it.

So – I’ve checked if aria-errormessage is being discussed in the W3C ARIA GitHub community and found an issue where somebody was suggesting that it should be deprecated (opens in new window).

The main argument was that we already have aria-describedby, but it felt totally wrong. As they are meant for two different things, aria-describedby is used to identify the element that contains a description (opens in new window) for the element that uses aria-describedby (connecting them via id value). The key point here is description, which can be anything, very general (and is currently most often additional information for input fields, like additional validation requirements). We must also remember that such descriptions can be actually turned off by screen-reader users if they prefer to. At least in some screen-readers (verbosity settings).

aria-errormessage, on the other hand, is specifically meant to identify the element that contains error message (opens in new window) -and is only exposed when aria-invalid is true. To my knowledge screen-reader users don’t have the possibility to disable such messages.

So – using aria-describedby for error messages is a “hack” that we need to use because aria-errormessage is not supported (enough) yet (OK, to be fair we can say that error message is additional description, but it’s not an optimal solution when we consider that announcements can be turned off and we would probably not want that error messages will not be announced to screen-readers).

Therefore I have been against deprecating aria-errormessage (opens in new window) and just wish it’s support would be better, so that we can finally start to use it.

Next version of NVDA (2024.3 stable) will support aria-errormessage

A nice GitHub feature is to be notified when somebody updates the issue and it’s even more nice when somebody informs involved people that a feature is on it’s way to production. Especially when the feature is a step towards a more accessible web.

So I can’t hide my excitement when I discovered that NVDA version 2024.3 (stable) will support aria-errormessage (opens in new window).

In contrast to aria-describedby NVDA users will not be able to disable aria-errormessage and, personally, I think that is actually a good thing. It’s always possible to stop screen-reader announcements by pressing the control key anyways.

Testing aria-errormessage with iPhone (VoiceOver and Safari) – beware potential bugs

As I don’t have JAWS at my hands right now, I tried to test how aria-errormessage works on iPhone (latest, with VoiceOver and Safari) and at first it seemed very easy, at least when I checked the documentation about it in ARIA 1.2.

But then I found that hiding error messages with different techniques was key when announcing error message on focus.

Considering simple HTML (full example for testing aria-errormessage):

<form method="POST">
   <label for="animal">Guess an animal <span aria-hidden="true">(required)</span>:</label>
   <input type="text" id="animal" name="animal" aria-required="true" aria-errormessage="animal_error" aria-invalid="true">
   <p role="alert"><span class="hidden" id="animal_error">⚠ Sorry, wrong animal...</span></p>
   <button type="button">Try my luck</button>
</form>

Span with id value animal_error uses class with value hidden. In my testing I may have discovered a bug (Safari and VoiceOver on iOS):

  • If we use HTML attribute hidden instead of class and remove it with JavaScript – then error message will not (!) be announced when we focus on the input field,
  • If we use CSS display:none; for hidden class and remove it – then error message will not (!) be announced when we focus on the input field,
  • If we use CSS visibility:hidden; for hidden class and remove it – then error message will be (!) announced when we focus on the input field – as expected,
  • If we use CSS opacity:0.01; for hidden class and remove it – then error message will be (!) announced when we focus on the input field – as expected.

Last case was not surprising, but I must say that I expected HTML attribute hidden, CSS display:none and CSS visibility:hidden to have same effect. They do not. I suspect it is a temporary bug (as they do have same effect on accessibility tree), will see if I can gather more info about it at some other time.

It is probably best to still use aria-describedby for error messages

I am looking at TalkBack – there is no support yet, at least on my updated TalkBack. If you are certain that your users will never use TalkBack (if you are so lucky that you absolutely know about that), then maybe, just maybe you can soon migrate to aria-errormessage.

But as always – be sure to test with different combinations and be sure to test with different users. I will stick with aria-describedby for some time, but will check the aria-errormessage more frequently, as it is obviously the best solution (when it will be supported).

Author: Bogdan Cerovac

I am IAAP certified Web Accessibility Specialist (from 2020) and was Google certified Mobile Web Specialist.

Work as digital agency co-owner web developer and accessibility lead.

Sole entrepreneur behind IDEA-lab Cerovac (Inclusion, Diversity, Equity and Accessibility lab) after work. Check out my Accessibility Services if you want me to help your with digital accessibility.

Also head of the expert council at Institute for Digital Accessibility A11Y.si (in Slovenian).

Living and working in Norway (🇳🇴), originally from Slovenia (🇸🇮), loves exploring the globe (🌐).

Nurturing the web from 1999, this blog from 2019.

More about me and how to contact me: