CtrlK
BlogDocsLog inGet started
Tessl Logo

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.

58

Quality

67%

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/label-content-name-mismatch/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 body is a well-organized overview with excellent progressive disclosure to a real one-level-deep reference, but it restates its core rationale redundantly, keeps all code/examples and verification steps in the reference rather than the body, and lacks an inline validation checkpoint.

Suggestions

Consolidate the voice-control explanation so it appears once; the intro, Quick Reference, and Explain sections currently make the same point three times.

Add one inline check method or code snippet (e.g., inspecting the computed accessible name in the browser DevTools accessibility pane, or a before/after aria-label example) so the body is actionable without the reference.

Add an inline verification step such as "Confirm via the browser accessibility tree that the visible text appears in the computed accessible name" to close the Check → Fix → Verify loop in the body.

DimensionReasoningScore

Conciseness

The body is short, but the voice-control rationale is restated three times — the intro sentence, Quick Reference bullet 2, and the Explain section — so not every token earns its place and it could be tightened.

2 / 3

Actionability

Guidance is concrete ("compare the visible text... with their 'aria-label' or 'aria-labelledby'", "include the exact string of the visible label text at the beginning") but incomplete: no inline code or concrete check method, with examples deferred entirely to the reference file.

2 / 3

Workflow Clarity

The Check → Fix sections give a clear simple sequence, but the verification/feedback checkpoint (automated + manual checks) exists only in the reference, so the body's workflow lacks an explicit validation step.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference — "see `references/rule.md`" — which exists and holds the detailed examples, matching the anchor for clean overview plus well-signaled shallow references.

3 / 3

Total

9

/

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 concrete and answers both what and when with an explicit "Use when" clause, but its trigger language is broader than the specific label/name rule and omits the most natural user-facing keywords (aria-label, voice control, label in name).

Suggestions

Add natural trigger terms users would actually say, such as "aria-label", "voice control", "label in name", and "WCAG 2.5.3", so the skill surfaces for the right requests.

Narrow the "Use when" clause to label/accessible-name mismatches specifically (e.g., "Use when a visible button or link label does not match its aria-label/accessible name") to reduce overlap with general accessibility-review skills.

Drop the awkward embedded title phrase "related to Align visible labels with accessible names" and restate the capability as a concrete action.

DimensionReasoningScore

Specificity

The description lists multiple concrete 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

It opens with an explicit "Use when reviewing..." trigger (when) and follows with "Check native semantics first, then inspect..." (what), clearly answering both with an explicit trigger clause.

3 / 3

Trigger Term Quality

Relevant terms appear ("accessible names", "keyboard behavior", "screen-reader output") but the most natural user-facing triggers for this rule — "aria-label", "voice control", "label in name", "WCAG 2.5.3" — are absent, leaving common variations missing.

2 / 3

Distinctiveness Conflict Risk

It is tied to a named rule, but the "when" trigger fires on any rendered HTML / interactive component / design-system review with broad accessibility-inspection terms, so it could overlap with general accessibility review skills.

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.