Names, roles & states

The Whole Page Is Hidden from Screen Readers

With `aria-hidden="true"` on the `body`, screen readers find nothing on the page, so blind visitors can't read or use any of it.

aria-hidden-bodyWCAG 2.0Introduced in WCAG 2.0.Level AA — the minimum. Missing it blocks people outright.

Status: CriticalCritical — Someone can complete the task only with great difficulty or outside help.CurrentScanners run this rule today.
Owner: DevTestProduct
Audit: AutomatedA scanner finds it, and a clean scan means it's fixed.

Why it matters

aria-hidden="true" tells screen readers (software that reads the screen aloud) to skip an element and everything inside it. On the body, that means the entire page.

It usually happens by accident. A pop-up script hides the page while a dialog is open, then fails to undo it. Sighted people notice nothing, so it can go unseen for months.

Who it affects

Who it affects, and how much
Who	What they experience	Impact
Screen reader users	They hear silence or "blank", and can't read headings, links or forms anywhere on the page.	High impact
Low-vision users (magnification)	Those who use a screen reader alongside magnification lose the spoken help completely.	Partial impact
Voice control users	Some voice tools can't find controls by name, so commands like "click Buy" may fail.	Partial impact

Business & product impact

Business & product impact, with how much each claim weighs
Area	Why	Impact
Legal	It fails WCAG 1.3.1 and 4.1.2 at Level A, the minimum, and EN 301 549. A fully blocked page is strong evidence in a Disability Discrimination Act complaint.	High impact
Conversion	Screen reader users can't sign up, search or pay. Every one of them leaves.	High impact
SEO	Search engines ignore `aria-hidden`, so there's no ranking gain here.	Low impact
Brand trust	A site that is completely silent looks careless, and people share that experience.	Moderate impact
Cost to fix	Usually a one-line fix in a shared modal or layout script.	High impact

Fixing it in code

Remove it from the body

Don't

<body aria-hidden="true">
  <main>…</main>
</body>

A screen reader says: “(nothing — the page is silent)”

<body>
  <main>…</main>
</body>

A screen reader says: “Main, landmark … the page reads normally”

The body must never be hidden, or nothing inside it can be reached.

Hiding the page behind a dialog

Don't

openBtn.onclick = () => {
  document.body.setAttribute('aria-hidden', 'true');
  dialog.hidden = false;
};

A screen reader says: “(nothing — the dialog is hidden too, because it sits inside the body)”

openBtn.onclick = () => {
  dialog.showModal();
};

A screen reader says: “Sign in, dialog”

showModal() hides the rest of the page for you and undoes it on close.

Designer's handoff note

When you spec a dialog or pop-up, note that only the content behind it is hidden — never the whole page.

Ask for a check that the page reads normally again after the dialog closes.

Quick test

Tool

NVDA (opens in a new tab) (free on Windows) or VoiceOver (opens in a new tab) (on every Mac)

Checklist

Step 1: Turn on the screen reader and load the page.
Step 2: Press H to jump between headings, or VoiceOver + right arrow to move on.
Step 3: Open and close any dialog, then try again.

Pass: You hear headings and content both before and after the dialog.
Fail: You hear nothing, or only the browser's controls.

What a green scan still misses

A scanner only sees the page at the moment it runs. It can miss a body hidden after a dialog opens and closes, so test that flow by hand.

Reference

Rule ID: aria-hidden-body
Raised by: axe-core: “aria-hidden="true" must not be present on the document body”
WCAG: 1.3.1 Info and Relationships (opens in a new tab) · Level A · since WCAG 2.0
4.1.2 Name, Role, Value (opens in a new tab) · Level A · since WCAG 2.0
Other standards: EN 301 549 9.1.3.1 · EN 301 549 9.4.1.2 · RGAA 10.8.1
Read more: Deque University: aria-hidden-body (opens in a new tab)
Last reviewed: 14 October 2026