aria-hidden-body

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Do not use aria-hidden on the document body. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

Quality

74%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/aria-hidden-body/SKILL.md

Quality

Content

65%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.

The body is well-structured as an overview with a clean one-level reference to rule.md, but it stays directional rather than executable and omits in-body validation checkpoints for the review workflow.

Suggestions

Add one concrete 'how to check' step in the Check section (e.g., an accessibility-tree selector or an axe/Lighthouse command) so the body is actionable without requiring the reference.

Surface an explicit validate/verify checkpoint inline (e.g., 'Re-run the accessibility checker to confirm <body> no longer carries aria-hidden') rather than deferring all verification to references/rule.md.

Collapse the Quick Reference bullets or merge them into the opening sentence to remove the redundancy between 'silences the entire application' and 'makes the entire page invisible'.

Dimension	Reasoning	Score
Conciseness	The body is lean and assumes Claude's competence, but the Quick Reference bullets restate the opening sentence ('silences the entire application' vs 'makes the entire page invisible to assistive technologies'), a minor redundancy that keeps it just below a 5.	4 / 5
Actionability	Guidance names concrete targets (remove aria-hidden from <body>, apply to background containers, flag elements/roles/labels/focus/keyboard), but the 'how' — actual inspection selectors, commands, or code — is deferred to references/rule.md, leaving key execution details missing.	3 / 5
Workflow Clarity	The Check/Fix/Explain/Code Review sections imply a sequence, but no explicit validation checkpoints appear in the body (verification lives only in references/rule.md), so checkpoints are implicit rather than present.	3 / 5
Progressive Disclosure	The body is a clear overview that points once to references/rule.md ('see references/rule.md') for full implementation details, code examples, and framework guidance — a well-signaled, one-level-deep reference with content appropriately split, matching the top anchor.	5 / 5
	Total	15 / 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.

The description clearly answers both what and when with an explicit 'Use when' clause and several concrete inspection actions, though it leans on a few too-broad trigger phrases that could overlap with sibling a11y skills.

Suggestions

Add natural accessibility synonyms ('a11y', 'ARIA', 'accessibility audit') to the trigger terms so users searching those phrases land on this skill.

Tighten the broad 'reviewing rendered HTML, interactive components, or design-system patterns' opening to lead with the rule-specific trigger and reduce overlap with other accessibility review skills.

Drop the 'where relevant' hedge on the inspection actions to make the capability list read as comprehensive rather than conditional.

Dimension	Reasoning	Score
Specificity	Lists several concrete inspection actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), with only minor coverage gaps; the 'where relevant' qualifier slightly weakens comprehensiveness, keeping it just below a 5.	4 / 5
Completeness	Both 'what' (check native semantics, inspect keyboard/focus/accessible-names/screen-reader output) and 'when' ('Use when reviewing rendered HTML, interactive components, or design-system patterns related to...') are answered explicitly with concrete trigger phrases, matching the top anchor.	5 / 5
Trigger Term Quality	Good keyword coverage with natural terms ('aria-hidden', 'screen-reader', 'keyboard behavior', 'focus flow'), but missing common accessibility synonyms such as 'a11y', 'ARIA', or 'accessibility' that users might say, so it falls short of a 5.	4 / 5
Distinctiveness Conflict Risk	The rule-specific trigger ('related to Do not use aria-hidden on the document body') carves a clear niche, but the broader 'reviewing rendered HTML, interactive components, or design-system patterns' phrasing overlaps with other accessibility review skills, so it is mostly distinct rather than minimal-conflict.	4 / 5
	Total	17 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/aria-hidden-body/SKILL.md
Commit: 30756a7

Reviewed: 16 days ago

Table of Contents

Discovery Implementation Validation

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.