WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-errormessage implementation


From: Wolfgang Berndorfer
Date: Aug 26, 2018 9:15AM

Hi Birkir,
Thanks for your reply and all research and interventions on jaws and nvda.
So now we could discuss (again):
A) We advice authors not to use aria-errormessage yet and just take
aria-invalid combined with aria-describedby. Sufficient semantic and
information are guaranted anyway.

B) We advice authors to use aria-errormessage conforming to specs and users
of AT to mob AT developers (mob for mobilization and mobbing).

Didn’t experience that aria-describedby referenced element is always
announced, even with display: none. Another issue for AT? And for web
authorss: No aria-describedby while the referenced element has display:
I’m surprised: Are announcements via aria-describedby or aira-erromessage
really depending on aria-invalid=true? Didn’t test it. Or did I
misunderstand You at this point?

-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: <EMAIL REMOVED> ] Im Auftrag
von Birkir R. Gunnarsson
Gesendet: Samstag, 25. August 2018 21:46
An: WebAIM Discussion List
Betreff: Re: [WebAIM] aria-errormessage implementation


YOu are right, screen readers have not implemented support for this
I've filed issues against NVDA and Jaws for this:
Jaws (issue 83):

The Jaws issue has no responses, the NVDA discussion evaporated.

The reason why aria-invalid is required with aria-errormessage is
basically the thing that makes it useful (over just using
If you reference an element with aria-describedby it is always
announced by a screen reader, regardless of its visibility (you can
hide it with display: none; and it is still announced).
So you can't, for instance, create the error association in the static
HTML and then change the visibility of the error message when user
makes an error, because a screen reader will always announce the error
If you connect it with aria-errormessage a screen reader should not
say anything until aria-invalid is set to false on the input.
INitial state (no error message displayed, no screen reader announcement):

<label for="phn">Phone number</label>

<input id="phn" type="text" aria-errormessage="err">
<span id="err" style="display: none;">Phone number must be 10 digits
and contain no other characters<;span>

User makes mistake and you add aria-invalid="true" to the input and
remove display: none; from the error message. Message is visible and
it should be announced by a screen reader when you focus the input

This, sadly, is not happening, and I don't understand why this has not
been implemented properly in any screen reader yet (as far as I know).
Why create attributes and encourage people to use attributes if they
are not supported? The webcontent author is responsible if users can't
access the page, even if he used the perfect ARIA and the problem lies
with the user's assistive technology.
Wel, that's touching on a topic that has been discussed here before. *grin*
Come on NVDA and Jaws folks, the ball is in your court!

On 8/24/18, Wolfgang Berndorfer < <EMAIL REMOVED> > wrote:
> Hi,
> Any ideas whether and how to use aria-errormessage? This attribute would
> useful, if it worked.
> I tested with IE and MF, JAWS and NVDA, in connection with aria-invalid
> aria-live and redundant with aria-describedby. And I had a web research.
> How it seems to me:
> 1. Browser and AT support is shaky and partially off spec. And
> Often the screen reader does not announce what the referenced ID-element
> would advise.
> 2. Combinations with other ARIA attributes (invalid, describedby, live)
> announce too verbose and often redundant information for screen readers.
> Example: Any idea, why aria-invalid MUST be used in conjunction
> (https://www.w3.org/TR/wai-aria-1.1/#aria-errormessage)? I'd assume that
> aria-errormessage is used only when the input is invalid.
> So how can we imply aria-errormessage responsibly at the moment?
> Curious about Your input and errormessages!
> Wolfgang
> > > > >

Work hard. Have fun. Make history.