Eight quick things to remember when using aria-owns

Published: 27 December 2025

Here are eight quick things to remember when using the aria-owns attribute.

This article looks at aria-owns from both a specification perspective and a practical, real-world perspective.

1. What aria-owns does

aria-owns lets you make elements behave as if they are parent and child for assistive technologies, even when they are not nested in the DOM.

More precisely, it allows you to indicate that one element owns one or more other elements, which assistive technologies are expected to treat as children of the owning element.

In the following example, two elements are not children of the first list. By using aria-owns, assistive technologies should treat these two elements as children of the first list.

<ul aria-owns="aaa bbb">
  <li>Fruit</li>
  <li>Vegetables</li>
</ul>

<p>Lorem ipsum dolor sit amet...</p>

<ul>
  <li id="aaa">Apples</li>
  <li id="bbb">Bananas</li>
</ul>

Potential accessibility tree result:

- Fruit
- Vegetables
- Apples
- Bananas

2. When aria-owns can be useful

Use aria-owns when:

• Visual or technical constraints prevent correct DOM nesting.
• You need assistive technologies to perceive a logical parent–child structure that cannot be represented in markup alone.

It is a last-resort structural fix, not a layout tool.

3. When aria-owns should not be used

As a best practice, do not use aria-owns when:

• The correct structure already exists in the DOM.
• You can fix the hierarchy by changing markup.
• You are trying to reorder content visually or for keyboard navigation.

If the DOM can be fixed, fix the DOM.

4. DOM order vs Tab order vs Accessibility tree order

These are independent systems:

• DOM order: Source order in the document.
• Tab order: Keyboard focus order (driven by DOM order, focusability, and tabindex).
• Accessibility tree order: What is exposed to assistive technologies.

In simple terms, aria-owns affects how the accessibility tree is exposed to assistive technologies. It does not change DOM order or tab order.

5. DOM children vs aria-owns children

In the accessibility tree:

• Owned elements are treated as children of the owner in addition to their DOM relationships.
• In practice, this usually means that aria-owns children are added after all DOM children have been processed.

Using our example from earlier, you can see that the two aria-owns elements appear last in order in the accessibility tree:

Potential accessibility tree result:

- Fruit (DOM child)
- Vegetables (DOM child)
- Apples (aria-owns child)
- Bananas (aria-owns child)

6. IDREF order matters

In most cases, browsers expose owned elements to assistive technologies in the order the IDs appear in the aria-owns attribute, rather than in document order.

Unlike aria-labelledby and aria-describedby, whose IDREF ordering is defined in the Accessible Name and Description Computation 1.2 specification, no equivalent rule or algorithm exists for aria-owns.

Because there is no universal rule for how aria-owns IDREFs should be prioritised or merged with DOM children, different browsers may interpret or apply ordering differently.

In the example below, bbb is exposed before aaa in current browser implementations, as this matches the order in the aria-owns attribute. This behaviour is not mandated by the specification:

<ul aria-owns="bbb aaa">
  <li>Fruit</li>
  <li>Vegetables</li>
</ul>
<p>Lorem ipsum dolor sit amet...</p>
<ul>
  <li id="aaa">Apples</li>
  <li id="bbb">Bananas</li>
</ul>

Potential accessibility tree result:

- Fruit
- Vegetables
- Bananas
- Apples

7. Defining all children when order is critical

If the exact order of children matters, extra care is needed.

Because aria-owns adds to existing DOM relationships rather than replacing them, DOM children may still appear before owned children.

To reliably control the order, you should list all children using aria-owns, including those that are already DOM children.

In the example below, DOM children have also been referenced by the aria-owns attribute to allow control of the order:

<ul aria-owns="aaa bbb ccc ddd">
  <li id="ccc">Fruit</li>
  <li id="ddd">Vegetables</li>
</ul>
<p>Lorem ipsum dolor sit amet...</p>
<ul>
  <li id="aaa">Apples</li>
  <li id="bbb">Bananas</li>
</ul>

Potential accessibility tree result:

- Apples
- Bananas
- Fruit
- Vegetables

8. Multiple references to the same ID

In practice, because aria-owns introduces structural relationships that cut across the DOM, it is especially sensitive to conflicts and complexity.

An element should not be referenced by more than one aria-owns. If this happens:

• User agents may ignore one or more ownership references.
• The resulting exposure to assistive technologies can become unpredictable.
• Some relationships may silently disappear.
• There is no guaranteed “winner”.

Conclusion

Bottom line: aria-owns is a last-resort tool. It is underdefined in the specification, inconsistently implemented, and highly sensitive to conflicts and context.

Do not treat it as a reliable mechanism for ordering or structuring content. If the DOM is logical and sequential to begin with, aria-owns is almost never needed and should be left alone.