CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-labels

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

58

Quality

67%

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

Quality

Content

57%

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

The skill body is well-structured with a clean progressive-disclosure split to a real reference file. It is held back by generic, non-executable guidance in the body, mild conceptual fluff, and verification steps that are implied rather than made explicit checkpoints.

Suggestions

Make the Fix section actionable with a minimal inline example (e.g. an icon button with and without `aria-label`) so the body is copy-paste ready rather than deferring all code to the reference.

Add an explicit verification checkpoint in the body workflow (e.g. 'Verify in the accessibility tree / axe that each interactive control exposes a discernable name before approving').

Trim the 'mystery meat' opener and the 'Explain how...' meta-instruction, which restate accessibility fundamentals Claude already knows.

DimensionReasoningScore

Conciseness

The body is short and mostly lean, but the 'mystery meat' opener and the 'Explain how clear labels... improve accessibility' meta-instruction restate concepts Claude already knows; these could be trimmed.

2 / 3

Actionability

Guidance is concrete in direction ('Add descriptive text content or `aria-label` attributes to all interactive elements') but generic and lacks executable examples or specifics in the body itself, with code deferred to the reference.

2 / 3

Workflow Clarity

The Check→Fix→Code Review structure gives a clear sequence, but validation/verification checkpoints are only implicit ('note how to verify the fix') and the concrete verification steps live in the reference rather than the body.

2 / 3

Progressive Disclosure

A concise overview with well-organized sections points to a single, clearly signaled one-level-deep reference ('see references/rule.md') that exists as a real file; navigation is easy and content is appropriately split.

3 / 3

Total

9

/

12

Passed

Description

77%

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 an explicit trigger and concrete action list, scoring well on specificity and completeness. It is weaker on trigger-term coverage and distinctiveness, where it leans on generic review language rather than the accessibility vocabulary users would naturally invoke.

Suggestions

Add natural accessibility trigger terms users actually say, e.g. 'Use when reviewing accessibility, ARIA labels, screen-reader support, or a11y audits of interactive elements.'

Tighten distinctiveness by leading with the accessible-naming niche ('Use when auditing interactive elements for missing or unhelpful accessible names / aria-labels') so it does not conflict with keyboard-, focus-, or contrast-focused accessibility skills.

Remove the awkward embedded phrase 'related to Provide accessible names for all interactive elements' and replace it with plain trigger wording.

DimensionReasoningScore

Specificity

Lists multiple concrete actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), matching the score-3 anchor of several specific actions.

3 / 3

Completeness

Explicit 'Use when...' trigger clause answers when, and the inspection list answers what; both are present with explicit triggers, so it is not capped at 2.

3 / 3

Trigger Term Quality

'reviewing rendered HTML, interactive components, or design-system patterns' gives some natural keywords but omits common variations users would actually say (accessibility, a11y, ARIA labels, screen reader); the embedded rule title 'Provide accessible names...' is awkward phrasing rather than a trigger term.

2 / 3

Distinctiveness Conflict Risk

The accessible-names qualifier narrows the niche, but 'reviewing rendered HTML, interactive components, or design-system patterns' could overlap with sibling accessibility skills (keyboard, focus order, color contrast), so it is not yet a clearly distinct trigger set.

2 / 3

Total

10

/

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.