CtrlK
BlogDocsLog inGet started
Tessl Logo

button-name

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

61

Quality

73%

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

Quality

Content

71%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.

A lean, well-structured overview body with excellent progressive disclosure to a real, one-level-deep reference file. Its weakness is actionability: the body's own guidance stays at the directive level (especially the 'Check' section) with all executable examples deferred to the reference rather than including one inline snippet.

Suggestions

Add one inline good/bad markup snippet (e.g., '<button aria-label="Close modal"><svg>...</svg></button>' vs an unlabeled icon button) so the Fix guidance is executable without opening the reference.

Make the 'Check' section concrete: specify how to scan (e.g., inspect rendered DOM for <button> elements lacking text content, aria-label, or aria-labelledby, or run the browser's accessibility tree/audit panel).

Tighten the 'Explain' and 'Code Review' sections into one short bullet list to trim the template-like wording.

DimensionReasoningScore

Conciseness

Sections are short and lean with no heavy padding, but the opening sentence ('Buttons without accessible names are announced as button by screen readers...') restates a concept Claude already knows, and the 'Explain'/'Code Review' sections are slightly wordy. Matches 'efficient; minor instances of over-explanation that could be trimmed'.

4 / 5

Actionability

The 'Fix' section names concrete techniques ('text content, an aria-label, or an aria-labelledby reference') but the body contains no code or selector examples, and the 'Check' section is vague ('Scan for buttons that lack descriptive text or accessible labels') with no concrete detection method — the executable examples live only in the deferred reference file. Matches 'some concrete guidance but incomplete'.

3 / 5

Workflow Clarity

A clear Check → Fix → Explain → Code Review sequence is present, and verification is mentioned ('note how to verify the fix with browser accessibility tooling or assistive tech'). Not 5 because verification stays general with no explicit validate-and-retry checkpoint.

4 / 5

Progressive Disclosure

The body is a well-organized overview (Quick Reference / Check / Fix / Explain / Code Review) with a single clearly signaled, one-level-deep reference ('see references/rule.md', verified to exist and contain the code examples and details). Content is appropriately split between overview and reference, matching the top anchor.

5 / 5

Total

16

/

20

Passed

Description

75%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.

A solid description with an explicit 'Use when...' trigger and a list of concrete inspection actions. Its main weaknesses are the awkward 'related to Provide accessible names for buttons' phrasing that muddles the capability statement, and missing natural trigger synonyms like aria-label or a11y.

Suggestions

Restate as a clean third-person capability sentence, e.g., 'Checks that every button has an accessible name via text content, aria-label, or aria-labelledby. Use when reviewing rendered HTML, interactive components, or design-system patterns for buttons, icon buttons, or ARIA labeling.'

Add common natural trigger terms users would say: 'aria-label', 'icon buttons', 'a11y', 'screen reader'.

DimensionReasoningScore

Specificity

Lists several concrete inspection actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), matching the 'several specific actions; minor gaps' anchor. Not 5 because the awkward 'related to Provide accessible names for buttons' clause blurs the capability statement rather than enumerating a fully comprehensive action list.

4 / 5

Completeness

Both 'what' (check native semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output) and an explicit 'Use when...' trigger are present. Not 5 because the 'what' is tangled into the 'when' clause instead of a clean, concrete statement of what the skill does.

4 / 5

Trigger Term Quality

Good natural keyword coverage ('rendered HTML', 'interactive components', 'buttons', 'accessible names', 'screen-reader') that users would plausibly say. A few common natural terms are missing (e.g., 'aria-label', 'icon button', 'a11y'), keeping it at the 'good coverage; a few natural terms missing' anchor rather than 5.

4 / 5

Distinctiveness Conflict Risk

The button accessible-name niche is distinct with specific triggers, but the broad lead-in 'reviewing rendered HTML, interactive components, or design-system patterns' creates minor overlap risk with general frontend/accessibility review skills, matching the 'mostly distinct; minor overlap' anchor.

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

Validation — 15 / 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.