About this AccessLint rule
When aria-hidden="true" is set on the <body> element, the entire page becomes invisible to assistive technologies. Screen readers will not announce any content, links, buttons, or form controls on the page. The result is a completely blank experience for users who rely on these tools.
This typically happens by accident. A common cause is JavaScript that toggles aria-hidden="true" on the <body> element when opening a modal dialog, then fails to remove the attribute when the modal closes. A bug in that toggle logic, or an unhandled error, can leave the attribute stuck on the <body> permanently.
Why this matters
Screen reader users navigate the page through an accessibility tree built from the DOM. The aria-hidden="true" attribute removes an element and all of its descendants from that tree. When applied to <body>, every element on the page is removed. There is nothing left for the screen reader to interact with: no headings, no links, no text, no form fields. The user has no way to perceive or operate any part of the page.
This is a failure of WCAG 4.1.2 Name, Role, Value (Level A), which requires that user interface components expose their name, role, and state to assistive technologies. When the entire document is hidden, no component meets this requirement.
How to fix it
Remove aria-hidden="true" from the <body> element. This fix is mechanical: find the attribute and delete it.
If the attribute is being set by JavaScript (for example, as part of a modal open/close pattern), fix the script so that it never applies aria-hidden to <body>. Instead, apply aria-hidden="true" to specific sibling containers of the modal. When the modal closes, remove the attribute from those containers.
Steps:
- Check the rendered HTML for
aria-hidden="true"on the<body>tag. - If it exists in the source HTML, remove it.
- If it is being added by JavaScript, find the code responsible and change it to target specific elements rather than
<body>. - Verify that the attribute is removed when any modal or overlay is closed.
Examples
Incorrect: aria-hidden="true" on the body
<body aria-hidden="true">
<h1>Welcome</h1>
<p>This content is invisible to screen readers.</p>
</body>
The entire page is hidden from assistive technologies. Screen reader users experience a blank page.
Correct: no aria-hidden on the body
<body>
<h1>Welcome</h1>
<p>This content is available to all users.</p>
</body>
Correct: hiding background content behind a modal
When a modal dialog is open, hide the page content behind it by targeting a specific wrapper element, not the <body>.
<body>
<div id="main-content" aria-hidden="true">
<h1>Welcome</h1>
<p>Main page content hidden while modal is open.</p>
</div>
<div role="dialog" aria-modal="true" aria-label="Confirm action">
<p>Are you sure?</p>
<button>Yes</button>
<button>No</button>
</div>
</body>
When the modal closes, the script should remove aria-hidden="true" from #main-content and remove or hide the dialog element. This keeps background content hidden from screen readers only while the modal is active, without ever touching the <body> element.
Detect accessibility issues automatically
Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.
Help us improve our guides
Was this guide helpful?
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial โJoin teams across 40+ countries