CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-dialog-name

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Ensure dialogs have an accessible name. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

67

Quality

81%

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

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 well-structured, lean, and uses progressive disclosure effectively by pointing to a real reference file. Its weakness is actionability and workflow clarity: the body itself contains no executable examples or explicit validation checkpoints, deferring all concrete code and verification steps to the reference.

Suggestions

Add at least one inline code snippet showing a correctly and incorrectly named dialog in the Fix or Quick Reference section so the body is self-contained for the common case.

Surface a brief verification step in the body (e.g. 'Verify the accessible name appears in the browser accessibility tree') instead of only in the reference, to add an explicit workflow checkpoint.

DimensionReasoningScore

Conciseness

The body is lean (~30 lines) and assumes Claude's competence, with no padding about what a dialog is; it is not 2 because every section earns its place rather than including unnecessary explanation.

3 / 3

Actionability

The body names two concrete attributes ('aria-labelledby (pointing to the header) or aria-label') but provides no executable code or examples in the body itself — those live only in the reference — so it stops at 'some concrete guidance but incomplete'; it is not 1 because it does name specific attributes rather than being purely abstract.

2 / 3

Workflow Clarity

Sections (Check → Fix → Explain → Code Review) give a present sequence, but the body has no explicit validation checkpoints or feedback loops, leaving checkpoints implicit; it is not 3 because validation steps are absent from the body itself.

2 / 3

Progressive Disclosure

The body is a concise overview with a clearly signaled, one-level-deep pointer to a real file ('see references/rule.md', which exists), matching the well-signaled one-level-deep anchor; it is not 2 because the split is clean and the reference path is genuine.

3 / 3

Total

10

/

12

Passed

Description

90%

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 includes explicit 'Use when' trigger guidance with good coverage of natural domain terms, giving strong completeness and distinctiveness. Its main weakness is second-person voice and the awkwardly embedded rule title 'Ensure dialogs have an accessible name', which lowers specificity.

Suggestions

Rewrite in third person (e.g. 'Reviews rendered HTML... and checks that dialogs have an accessible name') to avoid the second-person voice penalty.

Smooth the embedded phrase 'related to Ensure dialogs have an accessible name' so the rule title integrates grammatically instead of appearing as a pasted clause.

DimensionReasoningScore

Specificity

It names several concrete actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), which approaches the score-3 anchor of listing multiple specific actions, but the second-person voice ('Use when...', 'Check...') triggers the rubric's -1 specificity penalty.

2 / 3

Completeness

It explicitly answers both what (review/inspect dialog accessibility) and when via an explicit 'Use when reviewing rendered HTML...' trigger clause, matching the both-answered anchor; it is not 2 because the when-trigger is explicit rather than implied.

3 / 3

Trigger Term Quality

It covers natural terms a reviewer would say — 'rendered HTML, interactive components, design-system patterns', 'dialog', 'accessible name', 'keyboard behavior', 'screen-reader output' — matching the good-coverage anchor; it is not 2 because it is not missing common variations of the domain's vocabulary.

3 / 3

Distinctiveness Conflict Risk

The narrow niche ('related to Ensure dialogs have an accessible name') plus distinct trigger terms make it unlikely to fire for the wrong skill; it is not 2 because the scope is specifically dialog naming rather than a broad overlap-prone domain.

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