E-mail List Archives
Thread: aria-errormessage implementation
Number of posts in this thread: 7 (In chronological order)
From: Wolfgang Berndorfer
Date: Fri, Aug 24 2018 3:14PM
Subject: aria-errormessage implementation
No previous message | Next message →
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
From: Birkir R. Gunnarsson
Date: Sat, Aug 25 2018 1:45PM
Subject: Re: aria-errormessage implementation
← Previous message | Next message →
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 ADDRESS 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.
From: Wolfgang Berndorfer
Date: Sun, Aug 26 2018 9:15AM
Subject: Re: aria-errormessage implementation
← Previous message | Next message →
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).
Didnt 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:
none?
Im surprised: Are announcements via aria-describedby or aira-erromessage
really depending on aria-invalid=true? Didnt test it. Or did I
misunderstand You at this point?
Thanks!
Wolfgang
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Birkir R. Gunnarsson
Gesendet: Samstag, 25. August 2018 21:46
An: WebAIM Discussion List
Betreff: Re: [WebAIM] aria-errormessage implementation
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 ADDRESS 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.
From: Patrick H. Lauke
Date: Sun, Aug 26 2018 11:23AM
Subject: Re: aria-errormessage implementation
← Previous message | Next message →
On 26/08/2018 16:15, Wolfgang Berndorfer wrote:
> [...] Another issue for AT?
I'll just interject for a moment that support/lack of support for a
feature, or some funky behavior, isn't always down to AT, but to
browsers - whether they correctly expose information via the
accessibility tree/API etc.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Sun, Aug 26 2018 11:26AM
Subject: Re: aria-errormessage implementation
← Previous message | Next message →
The announcements for aria-describedby do not depend on aria-inavlid,
but announcements for aria-errormessage should depend on aria-invalid
(if aria-invalid is implemented properly by assistive technologies).
For now I advise my team to do one of two things:
Inject aria-describedby pointing to the error message id only when the
error message is visible (this can be hard to do, especially when you
build your site on templates).
or
have aria-describedby pointing to an empty error message container
element when the page load, then populate that element with the error
message when an error occurs.
This is technically invalid, aria-describedby shouldn't point to an
empty element, but it is better than nothing.
I still advise against the use of aria-errormessage due to lack of
user agent support, though I admit I am tempted to change the advice
and rely on assistive technology support to pick up eventually.
On 8/26/18, Wolfgang Berndorfer < = EMAIL ADDRESS REMOVED = > wrote:
> 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:
> none?
> 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?
> Thanks!
> Wolfgang
>
>
> -----Ursprüngliche Nachricht-----
> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
> von Birkir R. Gunnarsson
> Gesendet: Samstag, 25. August 2018 21:46
> An: WebAIM Discussion List
> Betreff: Re: [WebAIM] aria-errormessage implementation
>
> 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 ADDRESS 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.
> > > > >
> > > > >
--
Work hard. Have fun. Make history.
From: Birkir R. Gunnarsson
Date: Sun, Aug 26 2018 11:29AM
Subject: Re: aria-errormessage implementation
← Previous message | Next message →
Patrick
...
good point, there, I agree, it's up to the browser to expose the right
info to the assistive technology application.
But when the ARIA standard is updated, representatives from both
should by into the new or upated attributes and roles. I saw a
presentation at CSUN that for ARIA 2.0 the aim is to have at least two
combinations of browser and a.T. support new ARIA roles and attributes
at the time of publication, that would be really awesome.
NOw I am worried whenever I see new or altered ARIA attributes,
because, as good as they may sound, they may never be supported by
anybody, which makes them virtually useless, less than usueless
actually (if authors start relying on the without user support they
can make a bad web experience worse).
I"m not blaming anybody, I know it takes a lot of people and a lot of
collaboration, and I admire the people who are able to spend so much
time and bandwidth making the web a better place, I'm only expressing
some frustration on the implementation side.
On 8/26/18, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> The announcements for aria-describedby do not depend on aria-inavlid,
> but announcements for aria-errormessage should depend on aria-invalid
> (if aria-invalid is implemented properly by assistive technologies).
>
> For now I advise my team to do one of two things:
> Inject aria-describedby pointing to the error message id only when the
> error message is visible (this can be hard to do, especially when you
> build your site on templates).
> or
> have aria-describedby pointing to an empty error message container
> element when the page load, then populate that element with the error
> message when an error occurs.
> This is technically invalid, aria-describedby shouldn't point to an
> empty element, but it is better than nothing.
> I still advise against the use of aria-errormessage due to lack of
> user agent support, though I admit I am tempted to change the advice
> and rely on assistive technology support to pick up eventually.
>
>
>
> On 8/26/18, Wolfgang Berndorfer < = EMAIL ADDRESS REMOVED = >
> wrote:
>> 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:
>> none?
>> 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?
>> Thanks!
>> Wolfgang
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im
>> Auftrag
>> von Birkir R. Gunnarsson
>> Gesendet: Samstag, 25. August 2018 21:46
>> An: WebAIM Discussion List
>> Betreff: Re: [WebAIM] aria-errormessage implementation
>>
>> 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 ADDRESS 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.
>> >> >> >> >>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
>
--
Work hard. Have fun. Make history.
From: Wolfgang Berndorfer
Date: Sun, Aug 26 2018 1:12PM
Subject: Re: aria-errormessage implementation
← Previous message | No next message
Hi Birkir and Patrick,
Corect: Its not always the AT that is late and everywhere is worked hard.
And when I flippantly mentioned mobbing I ment showing up price policy or
monopole areas in AT scene. Hope, my statements wont lead to a fundamental
discussion.
-----Ursprüngliche Nachricht-----
Von: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] Im Auftrag
von Patrick H. Lauke
Gesendet: Sonntag, 26. August 2018 19:23
An: = EMAIL ADDRESS REMOVED =
Betreff: Re: [WebAIM] aria-errormessage implementation
On 26/08/2018 16:15, Wolfgang Berndorfer wrote:
> [...] Another issue for AT?
I'll just interject for a moment that support/lack of support for a
feature, or some funky behavior, isn't always down to AT, but to
browsers - whether they correctly expose information via the
accessibility tree/API etc.
P
--
Patrick H. Lauke
www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke