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.

Quality

62%

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/duplicate-id-aria/SKILL.md

Quality

Content

53%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 a well-organized, appropriately brief overview that delegates detail to a real one-level-deep reference file. Its weaknesses are generic one-line Check/Fix/Explain guidance with no concrete tools or verification steps in the body itself, plus mild redundancy (Quick Reference vs. Check/Fix) and an intro sentence explaining what Claude already knows.

Suggestions

Replace the generic Fix sentence with concrete remediation guidance in the body (e.g., deduplicate the id, point each ARIA attribute at its own unique target, or use a generator like React's useId), since the body currently says only 'update the references accordingly'.

Remove the concept-explaining intro sentence ('When ARIA attributes point to duplicate IDs, assistive technologies may read the wrong label or description') — Claude already knows this — and drop or merge the 'Quick Reference' bullets that repeat the Check/Fix sections.

Add an explicit verification checkpoint to the workflow (e.g., 'after fixing, re-check the browser accessibility tree or re-run axe's duplicate-id-aria rule') instead of only noting that the fix should be verified.

Dimension	Reasoning	Score
Conciseness	The intro sentence 'When ARIA attributes point to duplicate IDs, assistive technologies may read the wrong label or description' explains a concept Claude already knows, and the 'Quick Reference' bullets largely restate the Check/Fix sections. It is mostly lean but could be tightened by removing the redundancy.	3 / 5
Actionability	'Identify elements where an ARIA attribute references an id that appears multiple times in the DOM' names the detection condition, but the Fix guidance ('update the references accordingly') is generic and the body contains no concrete tools, selectors, or commands — those live only in the reference file. Some concrete guidance exists, but it is incomplete on its own.	3 / 5
Workflow Clarity	The Check → Fix → Explain → Code Review sections give a rough sequence, but validation is only implicit ('note how to verify the fix with browser accessibility tooling or assistive tech') with no explicit verification steps in the body. It is above a 2 because the section structure does order the work clearly.	3 / 5
Progressive Disclosure	The body is a short, well-sectioned overview with a clearly signaled one-level-deep pointer to 'references/rule.md', which exists and holds the code examples, tooling, and verification detail. Not a 5 due to minor content overlap between the body and the reference file.	4 / 5
	Total	13 / 20 Passed

Description

71%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 answers both what and when with several concrete inspection actions and a natural 'Use when' trigger, placing it solidly above the midpoint. Its main flaws are boilerplate trigger phrasing shared with sibling accessibility skills and an awkward embedded rule name that states the topic without naming the skill's core action of detecting duplicate ARIA-referenced IDs.

Suggestions

State the core capability as a concrete action, e.g., 'Detect and fix duplicate IDs referenced by ARIA attributes (aria-labelledby, aria-describedby, aria-controls)' instead of 'related to Use unique IDs for ARIA references'.

Narrow the 'Use when' trigger beyond the boilerplate 'reviewing rendered HTML, interactive components, or design-system patterns' to reduce overlap with sibling accessibility skills — e.g., add 'when auditing accessibility of rendered markup or investigating duplicate id/ARIA warnings from axe or Lighthouse'.

Dimension	Reasoning	Score
Specificity	'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' lists several specific inspection actions with only minor gaps. It falls short of 5 because the core capability — detecting duplicate IDs referenced by ARIA attributes — is never stated as an action, only implied by 'related to Use unique IDs for ARIA references'.	4 / 5
Completeness	Both parts are present: an explicit 'Use when reviewing rendered HTML, interactive components, or design-system patterns' trigger plus concrete inspection actions for the what. It is not a 5 because the awkwardly embedded rule name ('related to Use unique IDs for ARIA references') muddles the 'what' instead of stating a concrete capability like 'detect duplicate IDs referenced by ARIA attributes'.	4 / 5
Trigger Term Quality	Natural phrases like 'rendered HTML', 'interactive components', 'design-system patterns', 'ARIA references', and 'screen-reader output' give good keyword coverage. A few common terms are missing, such as 'accessibility', 'a11y', 'duplicate IDs', and specific attributes like aria-labelledby, so it does not reach comprehensive coverage.	4 / 5
Distinctiveness Conflict Risk	The trigger 'Use when reviewing rendered HTML, interactive components, or design-system patterns' is broad boilerplate that a whole family of sibling accessibility skills would share, so overlap risk is real. Distinctiveness rests entirely on the embedded rule name, which keeps it from dropping to 2 but does not clear the 'mostly distinct' bar of 4.	3 / 5
	Total	15 / 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/duplicate-id-aria/SKILL.md
Commit: 7bfd868

Reviewed: 1 day 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.