Using the aria-owns attribute
When a parent/child relationship is evident on-screen, but it isn’t represented in the DOM, the aria-owns attribute can be used to establish that relationship in the accessibility layer.
The parent/child relationship is a cornerstone of HTML structure. Every element in an HTML document is the parent, sibling or child of another.
In some cases these relationships are critical to the semantics of a document. A table contains rows, headers and cells for example. Without the correct arrangement of all the elements that the table consists of, the structure breaks down and becomes meaningless.
These relationships are not always available in the DOM though. Sometimes because of the way code is written, sometimes because the structures themselves do not exist. HTML has no elements for tree structures, and SVG has no concept of data structures like lists or tables for example.
Let’s take an artificial example, which isn’t likely to happen in the wild, but which makes it easier to explain how aria-owns works.
<ul>
<li>Fruit</li>
<li>Vegetables</li>
</ul>
<ul>
<li>Apples</li>
<li>Bananas</li>
</ul>
The two lists are separate in the DOM. Beyond the fact they are siblings in the DOM tree, they have no relationship with each other.
Now suppose that we want to change the way the lists are displayed, so that the second list appears as a child of the first. We could rewrite the source code and rebuild the DOM, or we could style the lists so they have the appearance of being nested.
The problem with the first option is that it takes effort and will probably effect performance. The problem with the second option is that it’s only cosmetic. An assistive technology like a screen reader (that relies on the DOM for information) will still consider the two lists as completely separate.
We can use the aria-owns attribute to fix this problem though.
<ul>
<li aria-owns="child">Fruit</li>
<li>Vegetables</li>
</ul>
<ul id="child">
<li>Apples</li>
<li>Bananas</li>
</ul>
The aria-owns attribute creates a parent/child relationship between the two lists in the accessibility layer. The DOM tree remains unchanged, but the accessibility tree now exposes the two lists as though they were nested. In other words, the lists are now exposed like this in the accessibility tree:
<ul>
<li>Fruit
<ul>
<li>Apples</li>
<li>Bananas</li>
</ul></li>
<li>Vegetables</li>
</ul>
Which is to say that is what should happen. Unfortunately screen reader support for aria-owns is still inconsistent.
Using this aria-owns test case, Jaws has support with Chrome, firefox and Internet Explorer. NVDA has support with chrome, but not Edge, Firefox or Internet Explorer. TalkBack does with Chrome, but VoiceOver does not in Safari (OSX or iOS).
Updated on 19th October to include results for Narrator (on Windows 10). The aria-owns attribute is not supported by Narrator with either Edge or Internet Explorer.
14 comments on “Using the aria-owns attribute”
Skip to Post a commentThank you for the interesting post, but you might want to double-check where is the test case link pointing to… 🙂
@DJN
Thanks. Should be fixed now.
Would it be appropriate to use this on DL/DT/DD elements, or is the serial-ness sufficient for #a11y?
@Eric
It’s always best to use HTML in the proper way – in this case by nesting the elements as the HTML spec requires. The aria-owns attribute is only a fix for those times when this really isn’t possible.
I’ve always used it with tab panels, but this opens my mind to navigation submenus.
I wanted to use aria-owns to join two lists instead of make one a subset of a node in the other’s group.
Like this:
A
B
C
D
So that we would end up with the accessibility DOM seeing this structure:
A
B
C
D
This only works well in Chrome. In Chrome, it does report to NVDA, list of four items, and each item has a bullet. In Firefox, even though the four items kind of appear under one list, it reports “list of 2 items” and the third and fourth items don’t get bullets. In IE 11 and in Edge, this is ignored altogether. Same results with Jaws 2018 as with NVDA.
Thoughts?
The HTML got stripped so I’ve put the example up at https://pac.bz/downloads/aria-owns-example.html
It looks like IA2 in Chrome correctly exposes the structure, but in Firefox the setsize and posinset properties are not exposed and the role of the second list is textframe. This probably accounts for the screen reader behaviour you’re witnessing. UIA doesn’t seem to expose the structure at all.
Thanks to Steve and Arron at TPG, who helped dig around under the hood for this info.
Thank you Leonie for your very clear and concise description
Thanks for this informative article. Do you have any update on screen reader report?
I’m afraid I don’t, no.
Hi Leonie
We had customers report new problems with Chrome 80 (Windows) that were caused by the incorrect use of aria-owns. We should have been using aria-controls. These issues were not happening with Chrome 79. So it may be time to do an update on the browser/screen reader support.
Ted,
I’ve just checked the aria-owns test cases with Jaws and NVDA in Chrome 80 and everything seems to be behaving as expected.
I’m not sure I understand the problems your customers reported though. Is it that aria-owns is no longer behaving as expected, or that aria-owns isn’t behaving as expected because it was used instead of aria-controls? Can you point to or share some example code?
Hi Leonie
We noticed incorrect use of aria-owns was ignored in Chrome 79, but is now being supported as expected in Chrome 80. It’s forcing us, rightfully so, to re-evaluate the use of aria-owns across our repository. So there may have been an increase in support within Chrome 80 or recent JAWS and NVDA combinations.