# Certain ARIA roles require specific child roles to be present.

> Canonical HTML version: https://rocketvalidator.com/accessibility-validation/accesslint/0.16/adaptable/aria-required-children
> Attribution: Rocket Validator (https://rocketvalidator.com)
> License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/)

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](https://www.w3.org/TR/wai-aria-1.2/) 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.

```html
<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`.

```html
<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.

```html
<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.

```html
<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.

```html
<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.

```html
<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.

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