How to fix aria required children on Headless / Custom (I build in code)

Steps for Headless / Custom (I build in code)

1. Search your component library for any element that sets a composite container ARIA role (role="listbox", role="combobox", role="menu", role="tablist", role="radiogroup", role="tree", role="grid") either as a static attribute or via JavaScript.
2. Cross-reference each container role with the required owned roles table in the WAI-ARIA specification and add the missing child roles to the appropriate descendant elements.
3. Prefer established accessible component libraries (Radix UI, Headless UI, Reach UI, Adobe React Aria) which implement the full ARIA role trees correctly out of the box, rather than building composite widgets from scratch.
4. For server-side rendered HTML, add role attributes directly in your template/JSX. For client-side rendered children, set the roles as soon as child elements are inserted into the DOM (not after a setTimeout).
5. Add automated accessibility tests (jest-axe, Playwright + axe-core) to your CI pipeline to catch regressions.
6. Manually test the complete widget with NVDA+Firefox and VoiceOver+Safari.

What is aria required children?

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.

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.

See the complete Aria required children guide for every platform and the full background.