Skip to main content
Accessibility.com, LLC
Category: ARIA and Semantic Structure

aria-hidden

Also known as: aria-hidden attribute, aria-hidden="true"
Simply put

aria-hidden is a code attribute that can be added to an HTML element to tell assistive technologies, such as screen readers, to ignore that element and not announce its content to the user. It is commonly used to hide decorative or duplicate content that would otherwise create a confusing experience. It should be used carefully, because hiding important or interactive content can prevent some users from accessing it.

Formal definition

aria-hidden is a WAI-ARIA state that, when set to "true", removes an element and its descendants from the accessibility tree, hiding it from the accessibility API used by assistive technologies while leaving it visually rendered. Per authoritative guidance, it should generally be applied only to non-interactive content; elements with aria-hidden="true" should not contain elements that are part of the sequential focus navigation and are focusable, as this can strand keyboard and assistive technology users on content that is announced-hidden but still reachable. Because aria-hidden affects only exposure to the accessibility API and not visual presentation or keyboard focusability, practitioners should verify its use through manual and assistive technology testing rather than relying on visual appearance alone.

Why it matters

aria-hidden directly controls what assistive technology users can and cannot perceive, which makes it one of the more consequential ARIA attributes to apply correctly. When used well, it removes clutter such as decorative icons or duplicated content that would otherwise create a confusing or repetitive experience for screen reader users. When used carelessly, it can hide important or interactive content from people who rely on assistive technologies, effectively removing functionality that remains visible to sighted users.

A particularly problematic pattern occurs when aria-hidden="true" is applied to an element that still contains focusable, keyboard-reachable content. Because the attribute affects only exposure to the accessibility API and not visual rendering or keyboard focusability, a keyboard or screen reader user can tab to a control that has been declared hidden from the accessibility tree. This creates a disorienting situation in which focus lands on content that is not announced, leaving the user with no clear indication of where they are or what the control does. Automated tools such as those referenced in the evidence digest flag this specific conflict, but automated detection identifies only a portion of potential issues.

Because the effects of aria-hidden are invisible in ordinary visual inspection, correct use should be confirmed through manual review and testing with actual assistive technologies rather than by appearance alone. This guidance is technical in nature and is not legal advice; how any given implementation relates to WCAG conformance or legal obligations depends on context and should be evaluated accordingly.

Who it's relevant to

Front-end and accessibility engineers
Developers who implement ARIA are responsible for ensuring aria-hidden is applied only to non-interactive, appropriate content and never wraps focusable elements. They should treat automated warnings about aria-hidden and focusable descendants as a signal to review the markup, and confirm behavior through keyboard and screen reader testing rather than visual inspection.
QA and accessibility testers
Because aria-hidden affects only the accessibility API and not visual presentation, testers cannot detect misuse by looking at the page. Manual testing with screen readers and keyboard navigation is needed to catch cases where hidden content is still focusable or where important content has been unintentionally suppressed. Automated checks help but detect only a portion of possible issues.
UX and content designers
Designers who specify decorative elements, duplicate labels, or icon-plus-text patterns should understand that aria-hidden may be used to remove redundant content from the screen reader experience. They should coordinate with developers to ensure that hiding content improves clarity without removing meaning that some users depend on.
Compliance and accessibility program owners
Those overseeing accessibility conformance should recognize aria-hidden misuse as a common source of barriers and ensure testing processes include manual and assistive technology verification. Correct use supports a better user experience but does not by itself guarantee conformance or legal compliance; questions about legal obligations should be directed to qualified counsel and evaluated against current requirements.

Inside aria-hidden

aria-hidden attribute
A WAI-ARIA state that, when set to 'true', removes an element and all of its descendants from the accessibility tree, hiding it from assistive technologies such as screen readers while leaving it visually present in the DOM.
Accessibility tree impact
Setting aria-hidden='true' prunes the element and its entire subtree from the accessibility tree, so nested content cannot be exposed to assistive technology even if a child attempts aria-hidden='false'.
Attribute values
The attribute commonly takes 'true' (hidden from assistive technology) or 'false'/absent (exposed). The 'false' value is generally treated the same as removing the attribute and does not override an ancestor's aria-hidden='true'.
Relationship to visual presentation
aria-hidden affects only exposure to assistive technologies; it does not hide content visually. Visual hiding is handled separately through CSS such as display:none or visibility:hidden.
Interaction with focusable elements
aria-hidden does not remove elements from the focus order. Applying it to a container that holds focusable controls can create a state where a keyboard user can focus an element that is hidden from screen reader users, which is generally discouraged.

Common questions

Answers to the questions practitioners most commonly ask about aria-hidden.

Does aria-hidden="true" hide an element visually from the page?
No. aria-hidden="true" does not affect visual rendering. The element remains visible to sighted users but is removed from the accessibility tree, meaning it is not exposed to assistive technologies such as screen readers. If you need to hide content both visually and from assistive technology, you must use additional techniques such as CSS display:none or the hidden attribute, which remove the element from both the visual layout and the accessibility tree.
Is aria-hidden the same as making an element non-focusable or removing it from the tab order?
No. aria-hidden="true" removes an element from the accessibility tree, but it does not remove focusable descendants from the keyboard tab order. If a focusable element (such as a link or button) is inside a container marked aria-hidden="true", a keyboard user may still be able to tab to it, creating a confusing state where the element receives focus but is not announced. To fully remove interactive elements from both the accessibility tree and keyboard navigation, focusability must also be managed separately, for example by removing the elements or making them non-focusable.
When should aria-hidden="true" be used?
It is commonly used to hide content that is redundant or purely decorative for assistive technology users, such as decorative icons that duplicate adjacent text, or off-screen or duplicated content that would otherwise be announced twice. It can also be applied to background content that is inert while a modal dialog is open. In each case the goal is to reduce noise in the accessibility tree without changing the visual presentation.
How should aria-hidden be handled for content behind a modal dialog?
A common pattern is to apply aria-hidden="true" to the page content outside the active dialog so that assistive technology users are not able to navigate into background content while the dialog is open, then remove it when the dialog closes. Because aria-hidden alone does not prevent keyboard focus from reaching focusable background elements, this is generally combined with focus management, such as trapping focus within the dialog. Note that the inert attribute is also increasingly used for this purpose where it is supported.
What happens if a focusable element is placed inside an aria-hidden container?
This creates an inconsistent state that is generally considered an error. The focusable element can still receive keyboard focus, but because its accessibility information is removed, assistive technologies may announce nothing or announce it incorrectly. Recognized guidance advises against placing focusable elements inside elements marked aria-hidden="true"; if such content should be hidden, its focusable descendants should also be made non-focusable or otherwise removed.
How can you verify that aria-hidden is behaving as intended?
Because aria-hidden affects how content is exposed to assistive technologies rather than visual rendering, testing should include manual review with screen readers and inspection of the accessibility tree using browser developer tools, in addition to any automated checks. Automated testing detects only a portion of potential issues and may not reliably identify cases such as focusable elements inside hidden containers, so manual and assistive technology testing are needed to confirm the intended behavior.

Common misconceptions

aria-hidden='true' hides content visually from all users.
It only removes content from the accessibility tree for assistive technology users. The content remains visible on screen unless it is also hidden with CSS.
Adding aria-hidden='false' to a child will re-expose it even when an ancestor is hidden.
Once an ancestor has aria-hidden='true', its descendants are removed from the accessibility tree, and a nested aria-hidden='false' generally cannot override that.
aria-hidden also removes elements from the keyboard focus order.
aria-hidden does not affect focusability. Focusable controls inside an aria-hidden container can still receive focus, which may confuse keyboard and screen reader users unless focusability is also removed.

Best practices

Use aria-hidden='true' only for content that is purely decorative or redundant to assistive technology users, such as icons paired with visible text labels.
Ensure no focusable elements exist within an aria-hidden='true' subtree, or remove them from the tab order, to avoid focusing content that is hidden from screen reader users.
Prefer CSS such as display:none or visibility:hidden when content should be hidden from all users, since these also remove content from the accessibility tree without the focus-order pitfalls.
Avoid relying on aria-hidden='false' to selectively re-expose descendants of a hidden ancestor, as this generally does not work; restructure the markup instead.
Verify behavior with manual testing using screen readers and keyboard navigation, since automated checks detect only a portion of accessibility issues.
Keep aria-hidden state synchronized with visual state changes (for example, when opening or closing modals or menus) so that hidden and exposed content stay consistent.