How to use the Focus Management Reviewer agent skill

What does the focus-management skill make the agent do?

Poor focus management leaves keyboard users stranded. They cannot find new content, get trapped in a closed modal, or lose their place after an interaction. The skill tells the agent to check whether focus is handled properly when a modal opens or closes, when the user moves between views, and when content updates on the page.

The agent works from a checklist rather than writing code for you. It first checks whether native HTML elements already handle the behaviour, then looks at keyboard flow, accessible names, and screen reader output where relevant. It flags the exact elements that break the rule. It can also suggest fixes using tabindex, focus() and focus trapping for modal dialogs.

• Move focus into a modal when it opens, and return focus to the trigger when it closes
• Move focus to new content after single-page app navigation or a dynamic update
• Use tabindex='-1' to make non-interactive elements focusable when focus needs to land on them
• Never leave focus at an unexpected location

How do you install the Focus Management Reviewer skill?

Download the ZIP file for the skill from the page where you found this guide. Unzip it so that the skill folder contains the files SKILL.md and references/rule.md. The skill is placed in a skills folder that your agent reads.

For a personal install, unzip the skill into ~/.claude/skills/. For a single project, unzip it into the project's .claude/skills/ folder so that only that project uses it.

If you use the Claude apps instead, open Settings, go to Capabilities, then Skills, and upload the skill there.

• Personal install: ~/.claude/skills/
• Project install: the project's .claude/skills/ folder
• Claude apps: Settings → Capabilities → Skills, then upload

How do you trigger the skill with a natural request?

You do not need a special command. Describe the review you want in plain language and mention the part of the interface you care about. The skill's description covers reviewing rendered HTML, interactive components, and design-system patterns that involve focus during dynamic interactions, so requests that name modals, menus, dialogs, or single-page app views are a good fit.

Be specific about the element or screen. A request that names a file, component, or page gives the agent something concrete to inspect, and it can then point to exact elements, roles, labels, and keyboard interactions.

• Review the focus behaviour of our login modal: does focus move in when it opens and return to the button when it closes?
• Check the mobile navigation menu for keyboard focus flow and accessible names.
• After route changes in our single-page app, is focus moved to the new page heading?
• Look at this rendered HTML for elements that break focus management and explain why.

What should you expect in the review output?

The agent first asks whether native HTML already does the job, because a correctly used button or dialog often needs less custom code. It then walks through keyboard behaviour, focus order, accessible names, and screen reader output where that is relevant to the component.

For each problem, the review should name the exact element and the rule it breaks. The skill also notes how to verify a fix with browser accessibility tooling or assistive technology, so you can confirm the result yourself after making changes.

• Native semantics checked first
• Keyboard flow and focus order
• Accessible names and labels
• Screen reader output where relevant
• Exact elements flagged, with suggested fixes and a way to verify them

What does the skill need, and what are the safety notes?

The skill lists no required tools or prerequisites. It does not run scripts and does not use the network, according to its listing. It is a set of instructions and reference material that the agent reads.

The skill is not a formal accessibility audit. Its guidance comes from a checklist, so it is not suitable where a certified compliance result is needed for legal purposes. It also does not apply to projects without any rendered UI, because focus behaviour does not come into play there.

• Requires: nothing listed
• Runs scripts: no
• Uses network: no
• Not a certified or legal compliance audit
• Not useful for projects without rendered UI

What tips help you get better focus reviews?

Review one interaction at a time. A modal, a menu, and a view change each have different focus rules, so a request that covers one of them gets a clearer answer than a request that covers an entire site.

Check the result with real tools after the agent suggests a fix. The skill itself points to browser accessibility tooling and assistive technology for verification, so do not treat the review text as the final test.

• Name one component or view per request
• Include the rendered markup or the component file when you can
• Test suggested fixes with a keyboard and a screen reader before release
• Use the review as a consistent step in your pre-release checks