CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-progressbar-name

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

62

Quality

74%

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

Quality

Content

78%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 content is a well-structured, lean accessibility rule with clean progressive disclosure to a real reference file. Its main weakness is the absence of inline executable examples and explicit verification checkpoints in the body itself.

Suggestions

Add one small inline HTML snippet showing a corrected progressbar with aria-label so the body is self-sufficient without opening the reference.

Merge or differentiate the ## Check section from the Quick Reference list to remove the duplicated 'check if all progress bar elements have an accessible name' wording.

Add a brief inline verification step (e.g., 'Confirm the name appears in the accessibility tree') to give the workflow an explicit checkpoint.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude knows ARIA basics, but the duplicated 'Check if all progress bar elements...' under ## Check repeats the Quick Reference guidance, leaving minor trim opportunities.

4 / 5

Actionability

Concrete directives are present ('Use aria-label or aria-labelledby', 'Provide aria-valuenow, aria-valuemin, and aria-valuemax') and the reference file holds executable HTML, but the body itself has no inline code example.

4 / 5

Workflow Clarity

The Check -> Fix -> Explain -> Code Review sequence is clear and the task is simple, but there are no explicit verification checkpoints or feedback loops in the body (verification lives only in the reference).

4 / 5

Progressive Disclosure

A concise overview with a single, clearly signaled one-level reference ('see references/rule.md') that exists in the bundle, with no nested references.

5 / 5

Total

17

/

20

Passed

Description

70%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 has a clear 'Use when' trigger and concrete review actions, scoring well on trigger terms and distinctiveness. It is capped slightly by the awkward 'patterns related to Provide accessible names' phrasing and a what/when pairing that is more generic than progress-bar-specific.

Suggestions

Reword the fragment 'design-system patterns related to Provide accessible names for progress bars' so the rule name is grammatically embedded rather than pasted in.

Tighten the 'when' clause to reference progress bars or loading states specifically, not just general HTML/component review, to sharpen distinctiveness.

Lead with the concrete capability (name progress bars via aria-label/aria-labelledby) before the review workflow to lift specificity.

DimensionReasoningScore

Specificity

The description names the domain and a couple of concrete actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but the coverage is review-oriented rather than a comprehensive list of distinct capabilities.

3 / 5

Completeness

It explicitly answers 'when' via 'Use when reviewing rendered HTML, interactive components, or design-system patterns...' and 'what' via the inspection actions, but the 'when' is somewhat generic to accessibility review rather than progress bars specifically.

4 / 5

Trigger Term Quality

It surfaces natural terms a user would say ('rendered HTML', 'interactive components', 'design-system patterns', 'keyboard behavior', 'accessible names', 'screen-reader output') with good coverage, though a few synonyms are missing.

4 / 5

Distinctiveness Conflict Risk

The progressbar-name focus plus the native-semantics-first framing distinguishes it from general accessibility skills, with only minor overlap risk against broad a11y review skills.

4 / 5

Total

15

/

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.