CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-hidden-focus

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Remove focusable elements from aria-hidden containers. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

64

Quality

77%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/aria-hidden-focus/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

71%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A lean, well-structured overview body that appropriately delegates detail to a single one-level-deep reference file with concrete check and fix guidance. The main weakness is redundancy: the why-explanation is repeated across the intro, 'Explain', and 'Code Review' sections, and templated title-splice phrasing pads otherwise tight text.

Suggestions

Remove the 'Explain' section — its content ('explain why focusable elements inside aria-hidden containers cause confusion...') duplicates the intro paragraph and adds no new instruction.

Replace the templated 'Code Review' paragraph with the concrete verification steps (e.g., axe/Lighthouse, keyboard-only navigation) from references/rule.md, or fold it into Check/Fix and drop the title-splice boilerplate ('that affect Remove focusable elements from aria-hidden containers').

Add a two-line inline HTML example of the incorrect vs. fixed markup (or explicitly point to the Code Example section of references/rule.md) so the fix is copy-paste ready from the body itself.

DimensionReasoningScore

Conciseness

Quotes: the intro 'the screen reader remains silent, leaving the user with no idea where their focus is' and the later 'Explain why focusable elements inside aria-hidden containers cause confusion for keyboard and screen reader users' restate the same rationale twice, and the 'Code Review' section largely reiterates Check/Explain. Not 4 because this duplication plus the template filler ('that affect Remove focusable elements from aria-hidden containers') accounts for roughly a third of the body; not 2 because there is no library-tutorial-style padding and the remaining lines are tight.

3 / 5

Actionability

Quotes: 'Scan `aria-hidden="true"` containers for focusable elements like links, buttons, or inputs.' and 'Add `tabindex="-1"` to focusable children inside `aria-hidden` containers or use the `inert` attribute.' — concrete scan targets and a specific, executable fix for an instruction-only skill. Not 5 because no example markup or selector is inline (it lives in references/rule.md) and the default-focusable element list is incomplete; not 3 because the given guidance has specific attribute values and named element types, not pseudocode.

4 / 5

Workflow Clarity

Quotes: 'Scan `aria-hidden="true"` containers...' (Check), 'Add `tabindex="-1"`...' (Fix), and 'note how to verify the fix with browser accessibility tooling or assistive tech' (verification hint) — a coherent check → fix → verify sequence for a simple single-rule skill. Not 5 because the verification pointer is vague (no named tool or step, and the detailed Verification section is only in the reference), and the 'Explain' section sits oddly in the sequence; not 3 because the steps are unambiguous and ordered with a verification cue present.

4 / 5

Progressive Disclosure

Quotes: 'For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`.' — the body is a lean overview with a single, clearly signaled, one-level-deep reference that exists in the bundle and matches what it promises (code examples, rationale, verification details). This matches the 5 anchor: clear overview, well-signaled reference, appropriate content split; no nesting or buried references.

5 / 5

Total

16

/

20

Passed

Description

83%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description that explicitly answers both what (inspect native semantics, keyboard behavior, focus flow, accessible names, screen-reader output) and when (reviewing rendered HTML, interactive components, design-system patterns), with concrete and natural trigger terms. Its main weaknesses are cosmetic — the mechanically spliced rule title mid-sentence and a few missing natural synonyms like 'accessibility' and 'tab order'.

DimensionReasoningScore

Specificity

Quotes: 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.' — several concrete, distinct inspection actions are named. Not 5 because the core remediation capability (adding tabindex="-1" or inert) is absent, leaving a minor gap in coverage; not 3 because the action list goes well beyond 1-2 actions and is domain-specific.

4 / 5

Completeness

Quotes: 'Use when reviewing rendered HTML, interactive components, or design-system patterns related to Remove focusable elements from aria-hidden containers' (explicit when with concrete triggers) and 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' (explicit what). Both what and when are clearly and explicitly present with concrete trigger phrases, matching the 5 anchor; the awkward title-splice is a style issue, not a completeness gap.

5 / 5

Trigger Term Quality

Quotes: 'rendered HTML, interactive components, or design-system patterns' and 'aria-hidden containers... keyboard behavior, focus flow... screen-reader output' — good natural keyword coverage for this niche. Not 5 because common variations a user might say — 'accessibility', 'a11y', 'tab order', 'inert', 'focusable' — are missing; not 3 because it goes beyond a couple of generic terms with multiple relevant, naturally-spoken phrases.

4 / 5

Distinctiveness Conflict Risk

Quotes: 'related to Remove focusable elements from aria-hidden containers' — a clear niche (aria-hidden/focus interaction) with distinct triggers. Not 5 because the broad opening 'reviewing rendered HTML, interactive components, or design-system patterns' is a shared template likely used by sibling accessibility rule skills, creating minor overlap risk with closely related skills (e.g., focus-management); not 3 because the aria-hidden/focus specificity pins it to one rule.

4 / 5

Total

17

/

20

Passed

Validation

93%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.