The aria-required-parent rule flags an element whose ARIA role only exists inside a particular container – a tab, an option, a menuitem, a listitem – but that is not inside it. Assistive technology then announces an item of nothing: no count, no position, no way to move to its siblings. The fix is to wrap the items in the container role they belong to, or to drop their roles.
What the rule means
WAI-ARIA defines a "required context role" for some roles: the container they must sit in. Common pairs:
tab→ insidetablistoption→ insidelistbox(or agroupinside one)menuitem,menuitemcheckbox,menuitemradio→ insidemenu,menubaror agroupinside onelistitem→ insidelist(or a native<ul>/<ol>)row→ insidetable,grid,treegridor arowgroup
The rule fails when such an element's nearest ancestor with a role is not one of its allowed containers. Elements in between with no role – plain <div>s – are ignored. The container can also claim the item with aria-owns.
Who is affected
Screen reader users. An option inside a listbox is announced with its position ("2 of 5") and can be reached with the arrow keys; an option on its own is announced as an option of nothing, and the arrow-key navigation the role promises does not exist. The whole widget reads as broken.
Why the check fails
- Roles copied onto items while the container keeps no role – a
<ul>ofrole="menuitem"links with norole="menu". - A wrapper with its own role between container and items, for example a
<section>with a name or arole="region". - Items rendered in a portal – a dropdown's options appended to the end of
<body>, away from their listbox. - Mixed patterns:
role="tab"used for a set of buttons that are not tabs at all. - Templates where the container is conditional and the items are not.
How to fix it
Put the items inside the container role they need.
<!-- Before: options with no listbox around them -->
<div class="dropdown">
<div role="option" aria-selected="true">Standard delivery</div>
<div role="option" aria-selected="false">Express delivery</div>
</div><!-- After: the listbox that gives the options their meaning -->
<div class="dropdown" role="listbox" aria-label="Delivery">
<div role="option" aria-selected="true">Standard delivery</div>
<div role="option" aria-selected="false">Express delivery</div>
</div>A listbox also needs keyboard support: focus on the listbox or its active option, arrow keys to move, and aria-selected kept in step. For a simple choice, native <select> or radio buttons give you all of that without ARIA.
How to test it manually
- In the browser's developer tools, select the item in the accessibility tree and check its parent's role.
- With a screen reader, move onto one item. Does it announce its position within the group?
- Use the arrow keys. Can you move between the items as the pattern promises?
- Open dropdowns and menus that render their items elsewhere in the page, and check them open.
Related WCAG criterion
1.3.1 Info and Relationships, Level A. Related: 4.1.2 Name, Role, Value, because a role that cannot work where it is placed tells assistive technology something untrue.
How Reviseberg reports it
Reviseberg runs aria-required-parent on every crawled page. The issue list shows the rule with its severity, WCAG 1.3.1, the number of affected elements and pages, and the points a fix gets you back; the detail view shows each item's selector and HTML snippet. Several items of one widget usually come from one component, so fixing the component clears them together. Dropdown options that are only rendered once the dropdown opens are not in the page axe checks, so they are neither found nor passed – open them and test by hand.