Guide · Agent skill
How to use the ARIA Hidden Focus Checker agent skill
Updated · written with AI from the project's own documentation and checked against our catalogue data
The aria-hidden-focus skill is an agent skill that tells an AI agent how to review HTML and interactive components for focusable elements sitting inside aria-hidden containers. After reading this guide you will know how to install the skill, how to ask for a check in plain language, and how to act on what the agent reports. No prior experience with agent skills is needed.
ARIA Hidden Focus Checkerthedaviddias/Front-End-Checklist · MIT Download the skill Quick start
- 1Download the ZIP. Get the aria-hidden-focus skill ZIP from its page on the directory.
- 2Unzip the skill folder. Extract it so SKILL.md and references/rule.md sit inside a skill folder.
- 3Place it in a skills folder. Put the folder in ~/.claude/skills/ for personal use, or in the project's .claude/skills/ folder.
- 4Or upload it in the Claude apps. Upload the ZIP under Settings → Capabilities → Skills.
- 5Ask for a review. Paste rendered HTML or a component and request a check for focusable elements inside aria-hidden containers.
- 6Apply and verify the fix. Add tabindex="-1" or the inert attribute as suggested, then confirm in a browser and with assistive technology.
What the skill makes the agent do
When an element has aria-hidden="true", it is removed from the accessibility tree, so screen readers skip it. It is not removed from the keyboard tab order. A keyboard user can tab into a link or button that the screen reader never announces, which the skill calls 'ghost' focus.
With the skill installed, the agent scans rendered HTML and interactive components for aria-hidden="true" containers that hold focusable children such as links, buttons or inputs. It reports the exact elements, explains why this confuses assistive technology users, and suggests fixes.
- Fix option 1: add tabindex="-1" to focusable children inside the aria-hidden container.
- Fix option 2: use the inert attribute on the container.
Install the skill from a ZIP file
Download the ZIP for the skill from the aria-hidden-focus page on the directory. Unzip it so that the skill folder, containing SKILL.md and references/rule.md, lands in one of these locations:
For a personal install available across projects, unzip into ~/.claude/skills/. For a single project, unzip into that project's .claude/skills/ folder.
In the Claude apps, you can instead upload the ZIP under Settings → Capabilities → Skills.
Trigger the skill with natural requests
You do not need a special command. Ask for a review in ordinary words that match the skill's description: reviewing rendered HTML, an interactive component, or a design-system pattern for focus inside hidden containers.
The skill's own guidance asks the agent to check native semantics first, then keyboard behaviour, focus flow, accessible names and screen-reader output where relevant.
- "Review this modal markup for focusable elements inside aria-hidden containers."
- "Check our drawer component for ghost focus."
- "Scan this menu's HTML for buttons a screen reader can't see but a keyboard can reach."
Example: reviewing a component
Suppose a component wraps a button in a container marked aria-hidden="true". The skill's reference file shows the failing pattern and two correct alternatives.
The reference marks the wrong version as ghost focus because the button can still be focused. The two correct versions either set tabindex="-1" on the button or put the inert attribute on the container so its contents cannot take focus.
<!-- ❌ Incorrect: Focusable but hidden from AT (Ghost Focus) -->
<div aria-hidden="true">
<button>I can be focused</button>
</div>
<!-- ✅ Correct: Using the inert attribute (modern browser support) -->
<div inert>
<button>Hidden Button</button>
</div>What you need and what the skill does not do
The skill lists no requirements. It does not run scripts and does not use the network. It is a review guide: its instructions tell the agent what to look for, and references/rule.md holds further examples.
It covers one narrow rule. It is not a full WCAG audit, and reading markup cannot replace testing with real assistive technology. The skill's own verification advice points to browser accessibility tooling or assistive tech for confirming a fix.
- Use it for: front-end developers, design-system teams checking modals, menus and drawers, and focused parts of an accessibility audit.
- Do not use it as: a complete accessibility audit or a substitute for screen-reader testing.
Tips for better results
Give the agent the rendered HTML or the component source, not only a description. It can only flag elements it can see.
Ask for the exact element, its role and label, and how to verify the fix. The skill's review guidance asks for these details.
Check the agent's suggested fix in a browser and with assistive technology before shipping, since the skill itself says that real screen-reader behaviour needs to be tested.
What people use it for
- Reviewing a modal dialog to make sure background content hidden with aria-hidden cannot receive focus.
- Checking a design-system menu or drawer for buttons or links inside hidden containers.
- Preparing a focused section of an accessibility audit on focus order.
Frequently asked questions
How do I install the aria-hidden-focus skill?
Download the skill ZIP from its page, then unzip it into ~/.claude/skills/ for personal use or into a project's .claude/skills/ folder. In the Claude apps you can instead upload the ZIP under Settings → Capabilities → Skills.
Does the aria-hidden-focus skill require anything else?
The skill lists no requirements. It does not run scripts and does not use the network, according to its listing.
Is this skill free and what is its licence?
The skill is listed under the MIT licence. This page does not state any price, so check the source listing for current terms.
Does this skill replace a full accessibility audit?
No. It covers one narrow rule about focusable elements inside aria-hidden containers. It is not a full WCAG audit.
Why is a focusable element inside aria-hidden a problem?
aria-hidden removes an element from the accessibility tree but not from the tab order. A keyboard user can focus it while the screen reader stays silent, so they cannot tell where focus is.
Should I use tabindex="-1" or the inert attribute?
The skill suggests either. tabindex="-1" removes a single element from the tab order, while inert on a container stops its contents from being focused, according to the reference examples.
New agent skills, repos and AI tools — every week
The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.
Our verdict
This skill suits front-end developers and design-system teams who want a focused check for focus inside aria-hidden containers, and it is easy to install with no requirements. If you need a full WCAG audit or real screen-reader testing, pick a broader audit tool or run assistive technology directly.
Download the skill