CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-roles

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Use valid ARIA role values. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

63

Quality

75%

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-roles/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

The content is a well-structured overview with good progressive disclosure to a real reference file, but its workflow steps lack explicit verification checkpoints and its guidance is only partially actionable, with some redundant meta-explanation. Tightening the Check/Fix steps and adding a concrete verification step would lift the weaker dimensions.

Suggestions

Replace the vague "Search for any role attributes..." Check step with a concrete method, e.g. a CSS/attribute selector like `[role]` or an axe/Lighthouse check command, so guidance is copy-paste ready.

Add an explicit verification checkpoint to the workflow (e.g. "Confirm the fix in the browser accessibility tree or with a screen reader before closing the review") rather than only implying it.

Trim or repurpose the "Explain" section so it does not instruct Claude to explain why standardized ARIA matters — a concept it already knows — and keep only reviewer-facing guidance.

DimensionReasoningScore

Conciseness

The body is mostly lean, but the "Explain" section directs Claude to explain why standardized ARIA roles are critical — a concept Claude already knows — and the "Code Review" section partly restates guidance, keeping it just above the fully-lean anchor.

2 / 3

Actionability

The Quick Reference gives concrete examples (use "checkbox" not "check-box"; prefer native <button>/<input>/<select>) but the "Check" step is vague ("Search for any role attributes...") with no specific selector, command, or tool, matching the incomplete-guidance anchor.

2 / 3

Workflow Clarity

Sequenced Check → Fix → Explain → Code Review sections are present, but verification is only weakly implied ("note how to verify the fix") with no explicit validation checkpoint in the body itself, fitting the "sequence present but checkpoints missing" anchor.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference ("see references/rule.md"), and references/rule.md exists with the detailed code, rationale, exceptions, and verification — matching the well-signaled one-level reference anchor.

3 / 3

Total

9

/

12

Passed

Description

92%

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 is strong, clearly stating both capability and trigger conditions with concrete accessibility-review actions and natural trigger terms. Its only weakness is a somewhat broad opening scope that could overlap with sibling accessibility skills, slightly weakening distinctiveness.

DimensionReasoningScore

Specificity

Lists multiple concrete review actions: "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output", matching the anchor for listing several specific concrete actions.

3 / 3

Completeness

Explicitly answers both what (check native semantics, inspect keyboard/focus/accessible-name/screen-reader behavior) and when ("Use when reviewing rendered HTML, interactive components, or design-system patterns"), satisfying the explicit-trigger anchor.

3 / 3

Trigger Term Quality

Covers natural accessibility-review terms users would say ("rendered HTML", "interactive components", "ARIA role values", "keyboard behavior", "focus flow", "accessible names", "screen-reader output") rather than jargon-only phrasing.

3 / 3

Distinctiveness Conflict Risk

The ARIA-role anchor narrows the niche, but the opening clause "reviewing rendered HTML, interactive components, or design-system patterns" is broad and could overlap with other frontend/accessibility review skills, matching the "somewhat specific but could still overlap" anchor rather than the clearly-distinct level.

2 / 3

Total

11

/

12

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.

Validation15 / 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.