AccessLint Rule: Certain ARIA roles require specific child roles to be present.

About this AccessLint rule

Certain ARIA roles define a parent-child relationship where the parent element must contain children with specific roles. When these required child roles are missing or incorrect, assistive technologies cannot interpret the structure of the component correctly. A list must contain listitem elements, a menu must contain menuitem elements, a grid must contain row elements, and so on. If the expected children are absent, the semantic meaning of the parent role breaks down.

Screen reader users are the most affected group. Screen readers rely on the accessibility tree to communicate the structure and content of a page. When a list role is present, for example, a screen reader announces how many items the list contains and allows the user to navigate between them. If none of the children have the listitem role, the screen reader may announce "list, 0 items" even though visible content exists, or it may not convey the list structure at all. The result is a confusing, incomplete experience.

This rule maps to WCAG 2.0 success criterion 1.3.1 Info and Relationships (Level A), which requires that information, structure, and relationships conveyed visually are also available programmatically. When a container role lacks its required owned elements, the structural relationship between parent and child is not programmatically determinable, and the criterion is not met.

How required child roles work

The WAI-ARIA specification defines, for many roles, a list of roles that their children must have. These are called "required owned elements." The ownership relationship is determined by the DOM hierarchy (direct children or descendants) or by the aria-owns attribute.

Here are some common roles and their required children:

list requires children with the listitem role
menu requires menuitem, menuitemcheckbox, or menuitemradio
tablist requires tab
grid requires row (directly, or row inside a rowgroup)
tree requires treeitem (directly, or treeitem inside a group)
table requires row (directly, or row inside a rowgroup)

Some relationships are nested. For instance, a menu can own a group, but that group must itself only contain menuitemradio elements. The required structure must be followed at every level.

Note that subclass roles do not automatically satisfy the requirement. A treeitem is a subclass of listitem, but it does not count as a valid child of list. Only the exact roles listed in the specification are accepted.

How to fix it

The fix depends on the situation. In many cases, the simplest approach is to switch to native HTML elements that carry the correct semantics by default.

If you need a list, use <ul> or <ol> with <li> elements instead of <div role="list"> with unsemantic children. Native HTML elements automatically establish the correct parent-child relationship in the accessibility tree without any ARIA attributes.

If you must use ARIA roles (for example, when building a custom widget that has no native HTML equivalent), make sure every child of the container has one of the required roles. Check the WAI-ARIA specification for the exact list of required owned elements for each role.

If a child element is purely decorative or structural (like a wrapper <div> used for styling), give it role="presentation" or role="none" so it is removed from the accessibility tree and does not interfere with the expected parent-child structure. Alternatively, restructure the markup so that the elements with the required roles are direct children of the container.

Be aware that aria-owns can also establish ownership, but browser support for it is inconsistent. Relying on DOM hierarchy is more reliable.

Examples

Incorrect: list role with no listitem children

The children of the list are plain <span> elements with no role. Screen readers cannot determine that these are list items.

<div role="list">
  <span>Item 1</span>
  <span>Item 2</span>
</div>

Correct: list role with listitem children

Each child has role="listitem", satisfying the required owned elements for list.

<div role="list">
  <span role="listitem">Item 1</span>
  <span role="listitem">Item 2</span>
</div>

Better: use native HTML instead

Native <ul> and <li> elements carry the correct semantics without any ARIA attributes.

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
</ul>

Incorrect: tablist with no tab children

The buttons inside this tablist do not have the tab role, so the relationship is broken.

<div role="tablist">
  <button>Tab 1</button>
  <button>Tab 2</button>
</div>

Correct: tablist with tab children

Each button now has role="tab", and the required parent-child structure is intact.

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

Incorrect: wrapper div breaks the required relationship

A styling wrapper sits between the list and the listitem elements. Some browsers may not resolve this correctly in the accessibility tree.

<div role="list">
  <div class="wrapper">
    <span role="listitem">Item 1</span>
    <span role="listitem">Item 2</span>
  </div>
</div>

Correct: wrapper has role="presentation"

Adding role="presentation" to the wrapper removes it from the accessibility tree, so the list directly owns the listitem elements.

<div role="list">
  <div class="wrapper" role="presentation">
    <span role="listitem">Item 1</span>
    <span role="listitem">Item 2</span>
  </div>
</div>