E-mail List Archives
Thread: Does aria-owns child need to exist prior to being used?
Number of posts in this thread: 6 (In chronological order)
From: Mark Magennis
Date: Wed, Dec 12 2018 3:25AM
Subject: Does aria-owns child need to exist prior to being used?
No previous message | Next message →
I'm looking at an aXe error: Invalid ARIA attribute value aria-owns="typeahead-list".
As you can probably guess, this is on a typeahead search input where a list of suggestions pops up when the user starts typing into the search field. aXe has been run when focus is not in the search field, before the list has appeared, but when the aria-owns attribute already exists with value of the future list's id.
My question is, will AT recognise the parent-child relationship if the id only exists after the field has received focus? Is timing likely to be an issue? For instance, if the list is created as soon as the search field receives focus, or not until the user types a character into the field?
Alternatively, what if the aria-owns attribute was also added dynamically at the same time as the list, either when the search field receives focus or when the user types a character?
Anyone know the answer so I don't have to create a test implementation?
Thanks,
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
From: glen walker
Date: Wed, Dec 12 2018 1:35PM
Subject: Re: Does aria-owns child need to exist prior to being used?
← Previous message | Next message →
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
From: Aditya
Date: Wed, Dec 12 2018 2:25PM
Subject: Re: Does aria-owns child need to exist prior to being used?
← Previous message | Next message →
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 ADDRESS 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
> > > >
From: Birkir R. Gunnarsson
Date: Wed, Dec 12 2018 3:07PM
Subject: Re: Does aria-owns child need to exist prior to being used?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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.
From: Mohith BP
Date: Thu, Dec 13 2018 4:57AM
Subject: Re: Does aria-owns child need to exist prior to being used?
← Previous message | Next message →
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 ADDRESS 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 ADDRESS 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 ADDRESS 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.
> > > > >
From: Mark Magennis
Date: Thu, Dec 13 2018 6:32AM
Subject: Re: Does aria-owns child need to exist prior to being used?
← Previous message | No next message
Thanks for that Glen. I guess this isn't specific to aria-owns. It's about any element that uses IDREFS.
Mark
Mark Magennis
Skillsoft | mobile: +353 87 60 60 162
Accessibility Specialist
-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of glen walker
Sent: 12 December 2018 20:35
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Does aria-owns child need to exist prior to being used?
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