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).