aria-owns — Redefining Parent-Child Relationships in the Accessibility Tree

In this tutorial, you will learn about aria. We cover key concepts, practical examples, and best practices to help you master this topic.

aria-owns establishes parent-child relationships between elements in the Accessibility tree that differ from their DOM hierarchy, useful for tree views, menus, and Composite widgets.

In this tutorial, you'll learn how to use aria-owns effectively in ARIA.

What You'll Learn

By the end of this lesson, you'll understand when to use aria-owns, how it differs from DOM parent-child relationships, and how it affects the accessibility tree.

Why It Matters

Sometimes the visual layout and the semantic relationship of elements do not match the DOM hierarchy. aria-owns bridges this gap.

Real-World Use

Doda Browser uses aria-owns in its tree-view file browser where visual tree branches are not direct DOM children of their parent node.

How aria-owns Works

flowchart LR
  A[DOM Tree] --> B[Parent has aria-owns]
  B --> C[References child IDs]
  C --> D[Accessibility Tree]
  D --> E[Child appears under parent]
  F[DOM structure unchanged]

Using aria-owns

aria-owns takes a space-separated list of element IDs that should appear as children in the accessibility tree:

<div role="menu" aria-owns="menuitem-1 menuitem-2">
  <!-- This menu has no DOM children -->
</div>
<div id="menuitem-1" role="menuitem">Open</div>
<div id="menuitem-2" role="menuitem">Save</div>

In the accessibility tree, menuitem-1 and menuitem-2 appear as children of the menu, even though they are elsewhere in the DOM.

When to Use aria-owns

Use aria-owns when DOM structure cannot match the semantic relationship:

<!-- Tree view where visual nesting differs from DOM -->
<ul role="tree" aria-label="Project files">
  <li role="treeitem" aria-expanded="true" aria-owns="child-1 child-2">
    <span>src</span>
  </li>
</ul>
<!-- Children defined outside the treeitem in DOM -->
<ul role="group" id="child-1">
  <li role="treeitem">index.js</li>
</ul>

aria-owns vs DOM Hierarchy

DOM hierarchy is always preferred. Only use aria-owns when you cannot restructure the DOM:

<!-- Preferred: DOM hierarchy matches semantics -->
<ul role="tree">
  <li role="treeitem">
    <span>src</span>
    <ul role="group">
      <li role="treeitem">index.js</li>
    </ul>
  </li>
</ul>

<!-- Alternative: use aria-owns when DOM cannot change -->
<ul role="tree" aria-owns="child-group">
  <li role="treeitem">src</li>
</ul>
<ul id="child-group" role="group" aria-owns="file-item">
  <!-- children -->
</ul>

Common Mistakes

• Using aria-owns when DOM hierarchy would work: Prefer DOM nesting.
• Referencing non-existent IDs: Broken references silently fail.
• Circular aria-owns references: Element A owns B, B owns A creates a cycle.
• Using aria-owns on non-ownership roles: Not all roles support aria-owns.
• Forgetting to update aria-owns when children change dynamically: Dynamic content requires dynamic aria-owns updates.

Practice and Challenge

1. What does aria-owns do? Creates a parent-child relationship in the accessibility tree between elements that are not DOM parent and child.

2. When should you use aria-owns? When DOM structure cannot match the semantic relationship.

3. Can aria-owns reference elements outside the parent element? Yes. That is its primary purpose.

4. What happens if the referenced ID does not exist? The ID is silently ignored.

5. Challenge: Create a menu where the menu items are not DOM children of the menu container. Use aria-owns to establish the relationship.

FAQ

Mini Project

Create a tree view where parent-child relationships use aria-owns because the visual layout requires a flat DOM structure.

What's Next

Continue to aria-flowto to learn about defining custom reading order.