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.

54

Quality

61%

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

72%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-organized, concise accessibility review skill that uses progressive disclosure effectively by keeping a lean overview and deferring detailed examples and verification to a single real reference file; it loses points on actionability and workflow clarity because the body lacks an inline code example and explicit verification checkpoints.

Suggestions

Include one small inline HTML snippet (a role="progressbar" with aria-label) so the skill is actionable without opening the reference.

Add an explicit verification checkpoint in the body (e.g. 'Confirm the accessible name appears in the accessibility tree/axe before considering the rule satisfied') to close the feedback loop.

Tighten the Check/Fix sections to reference the specific attribute pattern rather than restating the same guidance twice.

DimensionReasoningScore

Conciseness

The body is lean, assumes Claude knows what a progress bar and ARIA are, and adds only the rule-specific guidance (label requirements, value attributes, decorative-div caveat) without restating basics.

3 / 3

Actionability

It gives specific, actionable checks (use aria-label/aria-labelledby, avoid 'progress', provide aria-valuenow/min/max) but the body itself has no executable code or markup example — that concrete example lives only in references/rule.md.

2 / 3

Workflow Clarity

Check/Fix/Explain/Code Review sections sequence the review work, but there are no explicit verification checkpoints or feedback loops in the body itself; verification guidance is deferred to the reference file.

2 / 3

Progressive Disclosure

The SKILL.md is a concise overview with one clearly signaled, one-level-deep reference (references/rule.md, confirmed to exist) holding the full examples and verification steps; navigation is explicit and content is appropriately split.

3 / 3

Total

10

/

12

Passed

Description

50%

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 a recognizable accessibility niche, but a malformed/interpolated rule title ('related to Provide accessible names for progress bars') disrupts readability and the capabilities are framed as review activities rather than concrete deliverables.

Suggestions

Rewrite the description as a clean third-person capability statement, e.g. 'Reviews rendered HTML for progress bars (role="progressbar") missing accessible names and guides fixes with aria-label/aria-labelledby.', removing the interpolated rule title.

Add concrete trigger terms users would actually say — 'progress bar', 'aria-label', 'accessibility', 'screen reader' — alongside 'rendered HTML' and 'interactive components'.

State the deliverable explicitly (e.g. 'flags unnamed progressbars and suggests accessible-name fixes') so the 'what' is as clear as the 'when'.

DimensionReasoningScore

Specificity

Names a clear domain (accessible names for progress bars) and several inspection actions, but reads as a review checklist of activities rather than a list of concrete skill capabilities; the action verbs are audit steps, not deliverables.

2 / 3

Completeness

It includes an explicit 'Use when reviewing rendered HTML...' clause and describes what is reviewed, but the 'what does this skill do' is muddled by a malformed interpolated rule title ('related to Provide accessible names for progress bars'), so the 'what' is present but not cleanly stated.

2 / 3

Trigger Term Quality

Natural terms like 'HTML', 'interactive components', 'design-system patterns', 'focus flow', 'accessible names', and 'screen-reader output' appear, but common user phrasings ('progress bar', 'aria-label', 'accessibility') are only implied; the embedded rule title awkwardly interrupts the trigger list.

2 / 3

Distinctiveness Conflict Risk

The ARIA/progressbar niche is fairly distinct, but the generic 'reviewing rendered HTML, interactive components, or design-system patterns' framing could plausibly overlap with other accessibility or frontend-review skills.

2 / 3

Total

8

/

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.