WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-errormessage implementation

for

From: Birkir R. Gunnarsson
Date: Aug 25, 2018 1:45PM

Wolfgang

YOu are right, screen readers have not implemented support for this attribute.
I've filed issues against NVDA and Jaws for this:
NVDA:
https://github.com/nvaccess/nvda/issues/8318#issuecomment-405618407
Jaws (issue 83):
https://github.com/FreedomScientific/VFO-standards-support/issues/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
aria-describedby).
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
message.
If you connect it with aria-errormessage a screen reader should not
say anything until aria-invalid is set to false on the input.
e.g.
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
field.

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 be
> useful, if it worked.
>
>
>
> I tested with IE and MF, JAWS and NVDA, in connection with aria-invalid and
> 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 essentially:
> 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.