In one paragraph
Aria-hidden true on the document body requests that the page's body content be excluded from accessibility exposure while leaving ordinary visual rendering and interaction largely unchanged. Remove the inappropriate whole-page hiding and repair the component that applied it. Test active dialogs, background content, and focus during all close paths. Browser recovery varies, so do not rely on assistive technology ignoring the mistake.
Why it matters
A page can look normal while its meaningful content is hidden from accessibility APIs. Keyboard focus and accessibility exposure are separate systems, so users can still encounter confusing or silent focus stops when inappropriate hiding surrounds active controls.
Modal or overlay scripts are common sources, but inspect actual ownership instead of assuming one plugin is responsible. Route changes, failed cleanup, nested dialogs, or an exception can leave a global attribute behind after an overlay disappears.
Whole-page hiding can also affect audit coverage. Many checks skip hidden content or return incomplete results. A sudden reduction in other findings may reflect reduced applicability rather than a real accessibility improvement. Repair the boundary and reassess the page.
How WebAuditOS evaluates this finding
The supplied aria-hidden-body rule checks the top-level body's aria-hidden value in the rendered snapshot. A value matching true under its documented handling fails; absent or false does not create this finding. Critical impact maps to high severity.
The rule does not inspect every descendant hiding boundary or independently validate inert usage. A body hidden only after an untested interaction can be missed. Its snapshot and browser behaviour do not justify a promise that every supported user receives identical output.
How to fix it
- Inspect the body and relevant ancestor roots in the rendered page. Identify when the attribute is added: initial load, consent popup, modal opening, route transition, or error cleanup.
- Remove inappropriate body-level aria-hidden at its actual source. Do not merely set aria-hidden=false on one child; that does not reliably undo the hidden ancestor's effect.
- Redesign the overlay boundary so the active dialog and its controls remain exposed and operable. Background regions that genuinely need to be inactive should be handled without including the active interface in the same hidden or inert subtree.
- Prefer a well-supported native modal or a complete tested dialog implementation when appropriate. Calling a dialog modal through a role or attribute alone does not create focus management, background interaction handling, or reliable dismissal.
- Coordinate focus transitions. Move focus to the intended active interface when opening, keep its relevant navigation coherent, and restore focus to a meaningful location when closing. Handle Escape, explicit close, action completion, failure, and route changes.
- Use inert or hiding mechanisms according to their actual effects. aria-hidden is not a general click or focus lock; an inert attribute also does not provide visual styling by itself. Do not disable the body indiscriminately as a substitute for a deliberate boundary.
- Test nested overlays and repeated open-close sequences. Confirm cleanup occurs if a component unmounts or a request fails, not only on the happy-path close button.
- Rescan after restoring exposure and inspect newly applicable results. A larger finding count can be expected when previously hidden content becomes testable again; it is not evidence that this repair created every underlying issue.
What the fix can break
A patch that simply removes the attribute can expose an unresolved background-navigation problem in the modal. Fix the complete interaction, not only the literal failing value.
Multiple libraries can compete over global body state. Centralise or coordinate ownership so one overlay's cleanup does not undo another active dialog's intended behaviour.
Do not claim no hidden-body finding proves the entire accessibility tree is usable. A nested app root or other container can create related problems outside this rule's specific scope.
Questions
Can aria-hidden=false on the dialog fix a hidden body?
Do not rely on it. Repair the ancestor boundary so the active content is not inside an inappropriate hidden subtree.
Why did other violations disappear at the same time?
They may have become inapplicable because content was hidden from the engine. Restore exposure and retest.
Does aria-modal implement a complete dialog?
No. Actual interaction and focus behaviour must be supplied by the implementation or native mechanism.
Which related checks help?
Review hidden focus, bypass mechanisms, 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. axe declares this rule critical, so a failure arrives as high. The panel above shows a conformance level because for axe rules severity comes from the scan.