WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Does aria-owns child need to exist prior to being used?

for

From: Mohith BP
Date: Dec 13, 2018 4:57AM

It is better to test aria-owns properties on various platform and AT
combination as suggested by Glen.
The aria-owns attribute creates some issues with the screen readers
and the support is not robust among all the screenreaders.

On 12/13/18, Birkir R. Gunnarsson < <EMAIL REMOVED> > wrote:
> I think this issue should be filed for the aXe GitHub.
> aXe also calls violations when the target of aria relationship
> attributes exists but is empty.
> I think, except in the case of aria-labelledby that this should
> actually not necessarily be an issue.
> You may want to set up the aria-describedby relationship between a
> form field and an element containing an error message in the code,
> just keep that element empty until an error condition occurs, then
> populate it with the error message.
> The aria-errormessage attribute was created to address this situation,
> but based on my latest testing that attribute is not supported by any
> browser/assistive technology combination.
> I wrote an article on ARIA 1.1 for the Inclusive 24 series that is
> scheduled to be published on 12/22 and from there I link out to a
> bunch of Code Pens I created and issues I've filed with Jaws and NVDA.
>
>
>
> On 12/12/18, Aditya via WebAIM-Forum < <EMAIL REMOVED> > wrote:
>> In my opinion, unless it's aria-labelledby or aria-describedby, axe
>> should
>> not be reporting it. It makes sense to report missing ref for the above
>> two
>> because these Aria attributes are used in calculating accessible name.
>> For
>> aria-owns, aria-controls, it should not require that the id be present in
>> default state.
>>
>> Performance wise, it's better to change value of attributes rather than
>> adding attributes themselves.
>>
>>
>>
>>> On Dec 12, 2018, at 2:35 PM, glen walker < <EMAIL REMOVED> > wrote:
>>>
>>> I think if someone knew the answer, you should still create test
>>> implementations to verify, especially given the variety of
>>> AT/browser/platform combinations.
>>>
>>> I don't think it's well documented (at least that I've been able to
>>> find),
>>> about the timing of such things. If an element is created dynamically
>>> that
>>> is referenced in an IDREFS
>>> <https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#IDREFS> attribute
>>> (aria-labelledby, aria-describedby, aria-owns, aria-controls, etc), when
>>> does AT try to reference that object?
>>>
>>> I know when I'm viewing a page and have the code inspector up, I can
>>> change
>>> things dynamically in the code inspector and most of the time, AT will
>>> pick
>>> up the change. It's a nice way to test concepts without writing an
>>> example. (I say "most of the time" because occasionally I won't hear
>>> what
>>> I expected after a change, but I can't specifically point out what
>>> didn't
>>> work.) I'm usually adding new aria attributes, or changing the value of
>>> existing attributes. But the timing on doing that in the code inspector
>>> is
>>> quite different than the timing you'll have when doing stuff from
>>> javascript.
>>>
>>> Glen
>>> >>> >>> >>> >>
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >