HTML hidden versus aria-hidden: rendering and accessibility are different scopes

Use it for a real task

The decorative separator is visible but has no useful spoken meaning, so aria-hidden can keep it out of accessibility output. The future content is unavailable to everyone and uses hidden. Neither attribute is an access-control mechanism; both nodes remain in the delivered document.

<p>Receipt R-47 <span aria-hidden="true">|</span> Pending review</p>
<section hidden>
  <h2>Future export options</h2>
  <p>These controls are not ready.</p>
</section>

What the markup guarantees

Never put a focusable control under aria-hidden=true while leaving it keyboard reachable. For a whole inactive interactive region, use an appropriate state design such as hidden or inert and test the transition.

Cost and limits

The attributes add no network cost, but a mismatch between visual state, keyboard focus, and accessibility-tree state creates a hard-to-debug user failure.

Common Mistakes

• Do not use aria-hidden to visually hide text.
• Do not hide a focused descendant from the accessibility tree.
• Neither attribute keeps secrets out of page source.

Connected lessons

• HTML hidden and inert: remove inactive content from interaction deliberately
• HTML focus order: use native controls and keep DOM order usable
• HTML character references: escape data before inserting it into markup

Related: HTML hidden and inert: remove inactive content from interaction deliberately.