CtrlK
BlogDocsLog inGet started
Tessl Logo

duplicate-id-aria

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Use unique IDs for ARIA references. 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/duplicate-id-aria/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

The body is concise and well-structured, with good progressive disclosure that defers detail to a real reference file. Its weaknesses are actionability and workflow clarity: the inline guidance is somewhat abstract and lacks explicit verification checkpoints in the body.

Suggestions

Add a concrete detection snippet or tooling cue inline (e.g., a quick axe-core selector or a browser DevTools accessibility-tree check) so the Check section is executable, not just descriptive.

Include an explicit verification step in the body — a validate→fix→recheck loop referencing axe/Lighthouse or the accessibility tree — rather than deferring all verification to the reference.

DimensionReasoningScore

Conciseness

The body is lean across short sections (Quick Reference, Check, Fix, Explain, Code Review) and assumes Claude's competence without explaining what ARIA or HTML is, matching the score-3 anchor of lean, efficient content where every token earns its place.

3 / 3

Actionability

The "Check" and "Fix" sections describe what to look for in fairly abstract terms ("Identify elements where an ARIA attribute references an id that appears multiple times") without concrete tooling commands in the body, and executable code is deferred to the reference, matching the score-2 anchor of some concrete guidance but incomplete.

2 / 3

Workflow Clarity

The body presents a clear Check → Fix → Explain → Code Review sequence but contains no explicit validation or verification checkpoints in the body itself (verification lives only in the reference), so per the rubric's cap on missing validation steps it lands at the score-2 anchor of steps listed but validation gaps.

2 / 3

Progressive Disclosure

This simple, under-50-line skill is organized into clear sections and appropriately defers detail to a real, one-level-deep reference ("see `references/rule.md`" — confirmed to exist), matching the score-3 anchor for simple skills with well-organized sections and clearly signaled one-level references.

3 / 3

Total

10

/

12

Passed

Description

77%

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 specific and complete, clearly stating both what the skill does and when to use it with explicit triggers. Its main weakness is trigger-term quality: the keywords are fairly technical and could overlap with other accessibility review skills.

Suggestions

Add more natural user-facing trigger phrases (e.g., "duplicate ID", "aria-label points to the wrong element", "screen reader reads the wrong label") alongside the technical jargon so users' real-world phrasings match.

Tighten the duplicated rule title inside the description ("related to Use unique IDs for ARIA references") to avoid the awkward embedded repetition.

DimensionReasoningScore

Specificity

The description names the domain and 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 multiple specific concrete actions rather than the score-2 anchor of only some actions.

3 / 3

Completeness

It explicitly answers both what (the sequence of native-semantics, keyboard, focus, accessible-name, and screen-reader checks) and when (an explicit "Use when reviewing..." trigger clause), satisfying the score-3 anchor for clearly answering both what AND when with explicit triggers.

3 / 3

Trigger Term Quality

It opens with a "Use when reviewing rendered HTML, interactive components, or design-system patterns" clause, but the actual keywords are specialized jargon ("ARIA references", "accessible names", "screen-reader output") rather than natural phrasings a user would say, so it lands at the score-2 anchor of some relevant keywords missing common variations.

2 / 3

Distinctiveness Conflict Risk

It targets a distinct accessibility niche (duplicate IDs for ARIA references) but the broader framing of "reviewing rendered HTML, interactive components" could overlap with sibling accessibility review skills, matching the score-2 anchor of somewhat specific but still able to overlap.

2 / 3

Total

10

/

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.