label-content-name-mismatch

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

Quality

64%

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/label-content-name-mismatch/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 concise and well-structured with a clear one-level reference to an existing rule.md, but it lacks executable, concrete guidance and inline validation checkpoints. It reads as an overview stub rather than actionable instruction.

Suggestions

Add a concrete inline example showing how to detect a mismatch (e.g., an HTML snippet plus the comparison between visible text and aria-label/accessible name) so the guidance is executable without opening the reference.

Include an explicit verification step in the workflow, such as inspecting the accessibility tree or running axe, as a checkpoint after the Check/Fix steps.

Either move the directive prose into rule.md and keep SKILL.md as a pure pointer, or expand the inline Fix section with a copy-pasteable code pattern to raise actionability.

Dimension	Reasoning	Score
Conciseness	The body is brief and avoids explaining concepts Claude already knows, though the directive prose ('Compare the visible text...', 'Update the ARIA attribute...') adds little value beyond the referenced file, fitting 'efficient; minor instances that could be trimmed' just below the lean 5-anchor.	4 / 5
Actionability	Guidance is high-level ('Compare the visible text of buttons and links with their aria-label', 'Update the ARIA attribute to include the exact string') with no executable code, selectors, or commands, matching the 'minimal concrete guidance; high-level hints' anchor above the vague 1-anchor.	2 / 5
Workflow Clarity	Check/Fix/Explain/Code Review sections give a rough sequence, but there are no validation checkpoints or verification steps inline; it is a review (non-destructive) task so the destructive cap does not apply, fitting the 3-anchor 'sequence present but checkpoints missing'.	3 / 5
Progressive Disclosure	The body acts as an overview and clearly signals a one-level-deep reference ('see references/rule.md'), which exists as a real file; organization is good but the body sections are thin, placing it just below the ideal 5-anchor.	4 / 5
	Total	13 / 20 Passed

Description

75%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 states when to use the skill and enumerates several concrete inspection actions, with only minor gaps in trigger synonyms and explicitness of the 'what'. It is mostly distinct but has slight overlap risk with general accessibility-review skills.

Suggestions

Add an explicit 'what' clause naming the core action (e.g., 'Finds controls whose accessible name omits the visible label text') so the purpose stands alone from the rule title.

Broaden trigger terms with natural synonyms users say, such as 'aria-label mismatch', 'voice control labels', or 'WCAG 2.5.3 Label in Name', to improve trigger recall.

Tighten the accessibility scope to label/name alignment specifically to reduce overlap with broader a11y review skills.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — with only minor coverage gaps, fitting the 'several specific actions' anchor above the 3-anchor midpoint.	4 / 5
Completeness	Both 'what' (inspect semantics, keyboard, focus, accessible names, screen-reader output) and 'when' ('Use when reviewing rendered HTML...') are present, but the 'what' leans on the rule title and could be more explicit, matching the 4-anchor rather than the fully explicit 5-anchor.	4 / 5
Trigger Term Quality	'reviewing rendered HTML, interactive components, or design-system patterns' are natural terms a user would say, though common synonyms and explicit assistive-tech phrasing are under-covered, placing it just below the comprehensive 5-anchor.	4 / 5
Distinctiveness Conflict Risk	Tied to a specific WCAG rule with distinct triggers, but the broad accessibility-review framing could still overlap with closely related a11y skills, fitting 'mostly distinct; minor overlap risk' rather than the minimal-conflict 5-anchor.	4 / 5
	Total	16 / 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/label-content-name-mismatch/SKILL.md
Commit: 30756a7

Reviewed: 9 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.