Certain ARIA roles must be contained by particular parents

The WAI-ARIA specification defines a strict hierarchy for many roles. Some roles are only meaningful when they appear as children of particular parent roles. For example, a tab must be owned by a tablist, a listitem must be owned by a list or group, and a menuitem must be owned by a menu or menubar. When these parent-child relationships are missing, the role becomes semantically orphaned — assistive technologies like screen readers cannot communicate the element’s context, position, or purpose to the user.

Why This Matters

This rule relates to WCAG 2.0/2.1/2.2 Success Criterion 1.3.1: Info and Relationships (Level A), which requires that information, structure, and relationships conveyed visually are also available programmatically. When an ARIA role lacks its required parent, the structural relationship is lost in the accessibility tree.

Users most affected include:

• Blind and deafblind users who rely on screen readers. Without the correct parent role, screen readers cannot announce context such as “item 3 of 5 in a list” or “tab 2 of 4.”
• Users with mobility impairments who depend on assistive technology for navigation. Missing parent roles can break expected keyboard interaction patterns for composite widgets like menus, tablists, and trees.

The user impact is critical — an orphaned role can make an entire widget unusable for assistive technology users.

Common Required Parent Roles

Here are some frequently used roles and their required parents:

How to Fix the Problem

1. Wrap the element in its required parent role. The simplest fix is to ensure the DOM structure reflects the required hierarchy. Place the element inside a container that has the correct parent role.

2. Use aria-owns when DOM structure doesn’t match. If the child element cannot be a DOM descendant of the parent (e.g., due to layout constraints), you can use aria-owns on the parent element to establish the relationship programmatically. The aria-owns attribute tells assistive technologies that the referenced element should be treated as a child, regardless of DOM position.

3. Check the WAI-ARIA specification for the specific role you’re using to confirm which parent roles are required.

Examples

Incorrect: listitem Without a list Parent

The listitem role requires a parent with role="list" or role="group", but here it sits directly inside a plain div:

<div>
  <div role="listitem">Apples</div>
  <div role="listitem">Bananas</div>
  <div role="listitem">Cherries</div>
</div>

Correct: listitem Inside a list Parent

<div role="list">
  <div role="listitem">Apples</div>
  <div role="listitem">Bananas</div>
  <div role="listitem">Cherries</div>
</div>

Incorrect: tab Without a tablist Parent

<div>
  <button role="tab" aria-selected="true">Tab 1</button>
  <button role="tab" aria-selected="false">Tab 2</button>
</div>

Correct: tab Inside a tablist Parent

<div role="tablist">
  <button role="tab" aria-selected="true">Tab 1</button>
  <button role="tab" aria-selected="false">Tab 2</button>
</div>

Correct: Using aria-owns When DOM Structure Differs

When layout constraints prevent nesting the child inside the parent in the DOM, use aria-owns to establish the relationship:

<div role="tablist" aria-owns="tab1 tab2">
<!-- Tabs are elsewhere in the DOM due to layout needs -->

</div>

<div id="tab1" role="tab" aria-selected="true">Tab 1</div>
<div id="tab2" role="tab" aria-selected="false">Tab 2</div>

Incorrect: menuitem Outside a menu

<div>
  <button role="menuitem">Cut</button>
  <button role="menuitem">Copy</button>
  <button role="menuitem">Paste</button>
</div>

Correct: menuitem Inside a menu

<div role="menu">
  <button role="menuitem">Cut</button>
  <button role="menuitem">Copy</button>
  <button role="menuitem">Paste</button>
</div>

Learn more:

Deque Reference

Deque University - How To Fix

→

W3C Reference

W3C WAI ARIA 1.1 - Roles

→