Aria required children

What it is

ARIA (Accessible Rich Internet Applications) is a set of attributes that tells screen readers and other assistive technologies what a piece of your page does. Some ARIA roles are "composite widgets" — they are containers that only make sense when they hold specific child roles inside them. For example, a `role="listbox"` must contain items marked with `role="option"`, and a `role="combobox"` must own a `role="listbox"` (or similar) that in turn contains `role="option"` children. When those required children are missing, the widget is structurally broken from an accessibility standpoint. The scanner flagged WCAG Success Criterion 1.3.1 ("Info and Relationships"), which requires that the structure you communicate visually is also communicated to assistive technology — and a role hierarchy missing its required children fails that test.

Why it matters

Screen readers used by blind or low-vision shoppers rely entirely on correct ARIA role relationships to announce and navigate interactive controls like drop-down lists, autocomplete fields, product filters, and size/colour selectors. When required child roles are absent, the screen reader either announces the container as empty, skips it entirely, or narrates meaningless raw text — making the control unusable. This directly blocks those customers from completing purchases, which is both a lost conversion and a legal accessibility risk: WCAG 2.1 Level AA is the benchmark cited in ADA, EAA (Europe), and similar legislation, and regulators and plaintiffs increasingly target ecommerce stores. Fixing this also signals to Google that your pages are well-structured, which can contribute to crawl quality and Core Web Vitals signals over time.

How to fix it

1. Identify every element on the page that carries an ARIA container role (e.g. role="listbox", role="combobox", role="menu", role="radiogroup", role="tablist", role="tree", role="grid") — your scanner report will name the specific element and role.
2. Look up the required owned elements for that role in the ARIA specification (e.g. listbox → option; combobox → listbox containing option; menu/menubar → menuitem/menuitemcheckbox/menuitemradio; tablist → tab; tree → treeitem; radiogroup → radio; grid → row → gridcell).
3. Inspect the actual rendered HTML (browser DevTools → Elements tab) to confirm whether those child roles exist directly inside the container or are owned via aria-owns.
4. Add the missing role attributes to the correct child elements (e.g. add role="option" to each list item inside a role="listbox"), or refactor the markup so the DOM nesting matches what the ARIA spec requires.
5. If the children are present in the DOM but not yet loaded (e.g. rendered asynchronously), add aria-busy="true" to the container while loading and remove it — plus add the child roles — once the content is injected.
6. Re-test with an automated tool (axe DevTools, WAVE) and manually with a screen reader (NVDA+Firefox or VoiceOver+Safari) to confirm the widget is announced and navigable correctly.

Fix it on your platform

Pick your platform for the exact steps.

Frequently asked questions