In one paragraph
Certain ARIA roles must contain particular children means the tested role did not expose the structure expected by the rule. Inspect the rendered ownership and accessibility tree, including meaningful wrappers and loading states. Use native semantics where suitable or implement the complete ARIA pattern. Declaring tablist or another widget role does not automatically add keyboard handling, focus management, or valid child relationships.
Why it matters
A structural role makes a promise about content and behaviour. A list needs meaningful items; a tab list needs tabs related to panels. Incorrect structure can make assistive output misleading even when the visual layout appears complete.
Required ownership is not always equivalent to direct DOM children. Native semantics, wrappers, roles, and supported ownership relationships affect interpretation. The exact rule traversals are version-dependent, so avoid treating a simple CSS nesting change as universally correct.
ARIA declares semantics rather than installing an interaction library. Tabs still need selected-state updates, roving focus or the appropriate focus strategy, and expected keyboard handling. Structural validation covers only part of a working widget.
How WebAuditOS evaluates this finding
The supplied aria-required-children rule inspects applicable explicit roles and their required child relationships. Its documented implementation can look through plain wrappers while meaningful or focusable wrappers affect matching. Empty-role exceptions and aria-busy handling can yield different outcomes.
The supplied critical impact maps to high severity. Its report exposes axe violations, not all incomplete or needs-review results. An empty or busy component without a reported violation is not proof of a usable loading state, correct ownership, or a fully conformant widget.
How to fix it
- Identify the actual component and intended semantics. A static navigation group may need ordinary links and a list rather than an application menu role. Remove inappropriate ARIA only when native or simpler semantics truly fit the function.
- Inspect rendered DOM and the accessibility tree. Find required children, their roles, and any wrapper adding focus, its own semantic role, or another meaningful relationship. Do not assume the source component hierarchy equals the browser's resulting structure.
- Prefer native structural markup where suitable. A simple list can be:
<ul><li>Basic plan</li><li>Professional plan</li></ul>This avoids manufacturing a custom ARIA list for ordinary content. It does not replace the full structure required by a different interactive widget.
- For genuine ARIA widgets, follow the complete pattern. A tablist needs appropriate tab elements, labels, selected states, panel relationships, and keyboard logic. A few role attributes pasted into a snippet do not constitute a finished tabs implementation.
- Rework layout wrappers without discarding important semantics. Do not add role="presentation" to a meaningful or focusable element merely because it removes a test obstacle. Evaluate whether the wrapper should be outside the owned structure instead.
- Represent loading honestly. aria-busy can indicate ongoing updates but must return to the correct state when loading finishes. Keep useful status messaging and final content available; do not leave the component permanently busy to hide failures.
- Test empty, populated, loading, error, and dynamically updated states. Verify keyboard navigation and announcements with supported browser and assistive-technology combinations where practical.
- Rescan and review incomplete results separately when available. A clean violation list does not certify the relationships or interaction states the snapshot never exercised.
What the fix can break
Flattening the DOM can change CSS selectors, event delegation, or scrolling. Preserve behaviour while repairing semantics, and test at different viewport sizes.
Misusing aria-owns to force relationships can reorder the accessibility tree unexpectedly and introduce complex maintenance. Prefer a straightforward DOM design when practical.
Changing a role can change user expectations and announcement patterns. Do not label a component as a rich widget unless its actual keyboard and state behaviour supports that promise.
Questions
Do required children always have to be direct DOM children?
Not universally. Ownership and allowed structures depend on the role and accessibility model; the deployed rule has specific traversal logic.
Will a tablist role add arrow-key navigation?
No. The author must implement the complete tabs interaction pattern.
Is aria-busy a permanent fix for missing items?
No. It should describe a real temporary update, with a valid final state and useful feedback.
Which related checks help?
Review nested controls, form labels, and the automation limits guide.
What severity does this get in the report?
High. An axe finding takes its severity from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core, so a failure arrives as high. That is why the panel above states a conformance level rather than a severity - for other axe rules it depends on what failed.