CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-meter-name

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

61

Quality

72%

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/aria-meter-name/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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, concise overview with excellent progressive disclosure via a real one-level-deep reference, and the Check/Fix guidance is concrete and actionable. Weaknesses are mild redundancy across sections and verification steps being only implicitly referenced in the body rather than explicitly sequenced.

Suggestions

Collapse the Quick Reference bullets into the Check/Fix sections (or vice versa) to remove the restated content and tighten the body.

Add an explicit inline verification checkpoint (e.g., 'Verify: confirm the meter exposes the label in the accessibility tree via axe/Lighthouse') rather than deferring all verification to the reference.

Trim the meta-instructional 'Explain' section or merge it into 'Why It Matters' in the reference to reduce padding.

DimensionReasoningScore

Conciseness

Mostly efficient, but the Quick Reference bullets restate the Check and Fix sections, and the 'Explain' and 'Code Review' sections are somewhat padded and redundant with the description.

3 / 5

Actionability

Concrete, specific guidance — check for '<meter>' or role='meter' elements lacking an accessible name, then add 'aria-label' or 'aria-labelledby' — though executable code examples are deferred to the reference file.

4 / 5

Workflow Clarity

A Check→Fix→Code Review sequence is present, but validation/verification is only vaguely hinted ('note how to verify the fix with browser accessibility tooling') and the explicit verification steps live in the reference rather than the body.

3 / 5

Progressive Disclosure

A concise, well-sectioned overview points via a clearly signaled one-level-deep reference ('see references/rule.md') to a real file holding the code examples, rationale, exceptions, and verification steps.

5 / 5

Total

15

/

20

Passed

Description

80%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 both capability and trigger conditions with concrete review actions, scoring well on completeness and specificity. Its main weakness is distinctiveness: the trigger language is broad accessibility-review phrasing that risks matching sibling rules rather than uniquely signaling meter-element naming.

Suggestions

Add a meter-specific natural trigger phrase (e.g., 'Use when a meter or role="meter" element lacks an accessible name') so it distinctively matches this rule over sibling accessibility skills.

Replace the embedded rule title ('related to Provide accessible names for meter elements') with a natural clause that names the meter element and its labeling concern directly.

Tighten the generic review actions to focus on accessible-name provision for meter elements specifically, reducing overlap with general accessibility-review skills.

DimensionReasoningScore

Specificity

Lists several concrete review actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), though they are generic to accessibility review rather than meter-specific.

4 / 5

Completeness

Explicitly answers both 'what' (check native semantics, inspect keyboard/focus/accessible-name/screen-reader behavior) and 'when' (an explicit 'Use when reviewing rendered HTML…' trigger clause).

5 / 5

Trigger Term Quality

Good natural-term coverage ('rendered HTML', 'interactive components', 'design-system patterns', 'screen-reader'), but the meter-specific trigger appears only as the embedded rule title rather than a natural keyword.

4 / 5

Distinctiveness Conflict Risk

The trigger terms are generic accessibility-review phrasing that would overlap with many sibling a11y rules; the only distinguishing element is the awkwardly embedded rule title.

3 / 5

Total

16

/

20

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.