Modern accessibility tools and browser devtools have gotten very good at flagging potential issues. One warning that’s increasingly common in WordPress themes and plugins is about aria-hidden being “blocked,” “ignored,” or used in a way that hides focusable content. The warning is correct—and many of the popular fixes you’ll find online are either incomplete or flat-out wrong.
This article explains what “blocked aria-hidden” really means, why common fixes miss the point, and how to repair the problem without breaking your layout or your users’ experience.
Key Takeaways
aria-hidden="true"removes elements from the accessibility tree, not from visual display.- Accessibility tools warn when
aria-hiddenis applied to content that can still be focused or interacted with. - The goal is to make the accessibility tree match what is visually usable—not to silence the warning at any cost.
- Fixes often include adjusting focusability, changing markup, or rethinking how you show/hide elements, especially in WordPress themes and plugins.
- Use simple, testable patterns so that future edits or plugin updates don’t break accessibility again.
What “Blocked aria-hidden” Actually Means
aria-hidden is an ARIA attribute that tells assistive technologies (like screen readers) whether to ignore a piece of the DOM. For example:
<div aria-hidden="true">
This content will not be announced to screen readers.
</div>
When a tool says “blocked aria-hidden” or warns that aria-hidden is being ignored, it usually means:
- There is a focusable or interactive element inside a container with
aria-hidden="true", and - The browser or assistive technology has decided not to honor
aria-hiddento avoid hiding something the user can still interact with.
In other words, the warning is not a “bug” in the tool. It’s telling you that your code is asking for an impossible combination: content that is both interactive and invisible to assistive tech.
Why This Matters
Screen reader users depend on consistent, logical interfaces. When focusable elements are hidden in the accessibility tree, they may:
- Get stuck in focus traps.
- Encounter controls that are not labeled or discoverable.
- Miss important functionality entirely.
The warning is there to protect users from these situations. Your job is to make the UI and the accessibility tree line up.
Common “Fixes” You See Online (and Why They’re Wrong)
If you search for “blocked aria-hidden WordPress” or similar, you’ll often see advice such as:
- “Just remove
aria-hiddenand you’re done.” - “Force it with
aria-hidden="true"andtabindex="-1"on everything.” - “Ignore the warning; it’s a false positive.”
- “Hide it with CSS only, not ARIA.”
Each of these can make things worse.
Problem 1: Removing aria-hidden Without Rethinking Structure
If you remove aria-hidden from an off-screen menu, modal overlay, or “hidden until open” UI element, you may expose a lot of irrelevant or duplicate content to screen readers. That can make the experience noisy and confusing.
Example: A mobile navigation menu that is visually hidden but still fully present in the DOM. If you simply drop aria-hidden without adjusting visibility and focus behavior, screen reader users will tab through links they cannot see.
Problem 2: Forcing Everything to Be Hidden
Setting aria-hidden="true" on whole sections or reusable patterns just to silence warnings can hide genuine functionality. If there is a button, link, or form control inside, you are effectively trying to hide it from assistive tech while keeping it usable for sighted users. That conflict is what triggered the warning in the first place.
Problem 3: Ignoring the Warning
In some browser and AT combinations, aria-hidden will be honored even when it shouldn’t be. Assuming that all tools will protect you from bad markup is risky. Ignoring the warning means leaving real users to discover the failure.
Problem 4: CSS-Only Hiding Without Managing Focus
Using only CSS like display:none, visibility:hidden, or off-screen positioning can help visually, but it doesn’t automatically fix focus behavior. An element might be visually hidden but still focusable via keyboard, creating a confusing “invisible tab stop.”
The Real Goal: Align Visibility, Focus, and Accessibility
A correct fix doesn’t start with “how do I silence the warning?” It starts with three questions:
- Should the user be able to see this?
- Should the user be able to interact with this?
- Should a screen reader know about this?
Your solution should make these answers consistent. If an element is visible and interactive, assistive tech should know about it. If it’s hidden and not interactive, it can be safely removed from the accessibility tree.
How to Actually Fix aria-hidden Issues in WordPress
Most WordPress-related aria-hidden warnings come from a few common patterns: navigation menus, carousels, accordions, modals, and decorative icons. Here’s how to approach fixing them.
1. Fix Hidden But Focusable Elements
If a warning points to an element that is visually hidden but still focusable:
- Ensure it is not focusable when hidden (remove
tabindex, don’t usehreforbuttonwhen it’s not available). - Use CSS to hide it (
display:noneorvisibility:hidden) and, when appropriate, combine this witharia-hidden="true". - When the element becomes visible (e.g., menu opens, tab is activated), remove
aria-hidden, restore focusability, and update any ARIA states.
This typically involves adding or refining a small bit of JavaScript in your theme or plugin to synchronize:
- CSS visibility
- Focusability (tab order)
- ARIA attributes (
aria-hidden,aria-expanded,aria-controls)
2. Use aria-hidden Only for Non-Interactive or Decorative Content
Good uses of aria-hidden="true" include:
- Decorative icons that are explained via text labels elsewhere.
- Duplicate visual labels (e.g., a styled heading that is repeated in accessible text).
- Visual-only elements like background graphics or separators.
Bad uses include applying aria-hidden="true" to:
- Buttons, links, or inputs.
- Containers that include any of the above.
- Whole sections of content that are part of the main task flow.
In WordPress, many icon libraries and block patterns ship with aria-hidden already applied. Before changing them, confirm whether the content is truly decorative or redundant.
3. Modernize How You Show and Hide UI Components
Legacy themes and older plugins often mix visual hiding with incomplete ARIA usage. Consider modern patterns for:
- Menus: Use a button with
aria-expandedandaria-controls, toggle a CSS class to hide/show the menu, and only applyaria-hiddenwhile it is closed. - Accordions: Pair each toggle with a region, manage
aria-expanded, and only hide the region (via CSS and optionallyaria-hidden) when collapsed. - Modals: Trap focus inside the modal when open, hide background content with
aria-hiddenor inert-like patterns, and restore the page when the modal closes.
Updating to these patterns not only fixes the warning but makes your site more maintainable across theme or plugin updates.
4. Clean Up Overlapping or Conflicting Attributes
Sometimes the warning appears because multiple plugins or blocks are trying to “help” at the same time. For example:
- A plugin adds
aria-hidden="true"to icons. - Your theme wraps those icons in another container with its own ARIA attributes.
- Custom JavaScript later toggles visibility without updating ARIA.
Audit the HTML output (using your browser’s inspector) to see what the final markup looks like on the page, not just in your PHP or block editor. Then:
- Remove redundant
aria-hiddenon wrappers. - Keep ARIA attributes as close as possible to the element whose behavior they describe.
- Ensure that only one script or component is responsible for a given UI pattern.
Testing Your Fixes
Once you’ve updated your markup or scripts, verify:
- With keyboard only: Can you tab through the page logically, without landing on invisible or nonsensical elements?
- With accessibility checkers: Do tools like Lighthouse, axe, or the browser’s built-in accessibility panel still show warnings?
- With a screen reader: Use NVDA (Windows) or VoiceOver (macOS) to experience your site as a non-visual user would.
The goal is not to get “zero warnings” at any cost, but to ensure that what’s clickable, seeable, and announced all match up.
Conclusion: Honor the Warning, Fix the Cause
“Blocked aria-hidden” is not an annoyance to be silenced. It’s a signal that your markup is asking assistive technologies to hide something that still matters. The right fix depends on your UI pattern, but it always comes back to the same principles:
- Don’t hide interactive content from assistive tech.
- Keep hidden content out of the focus order.
- Synchronize visual state, focus behavior, and ARIA attributes.
When you treat the warning as a design and implementation problem—not just a validation error—you make your WordPress site more usable for everyone and easier to maintain as your theme and plugins evolve.
If you want help auditing and improving accessibility patterns in your WordPress site—without breaking your existing design—Izende Studio Web can assist with review, remediation, and ongoing support.