WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: aria-errormessage implementation

for

From: Birkir R. Gunnarsson
Date: Aug 26, 2018 11:29AM

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