CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-toggle-field-name

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

49

Quality

53%

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-toggle-field-name/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 is well-structured with a clean overview and a single clearly-signaled reference file holding the detailed examples. Its weaknesses are an unnecessary concept explanation up front, tautological meta-instruction sections, and the absence of an explicit verification checkpoint in the workflow.

Suggestions

Remove or trim the opening sentence explaining why unlabeled toggles are unusable for screen reader users; Claude already knows this.

Replace the tautological Check/Fix/Explain meta-instructions with concrete, copy-paste-ready markup patterns, or surface the examples from references/rule.md inline.

Add an explicit verification checkpoint to the Check -> Fix sequence (e.g., 'Confirm the fix in the browser accessibility tree or with axe') so the workflow has a feedback loop.

DimensionReasoningScore

Conciseness

The body is short overall, but it opens by explaining a concept Claude already knows ('Toggle fields... are unusable for screen reader users if they don't have a label') and the Check/Fix/Explain sections are tautological restatements that could be tightened.

2 / 3

Actionability

The Quick Reference names concrete techniques ('aria-label', 'aria-labelledby', '<label>'), but the Check, Fix, and Explain sections give vague meta-direction ('Add an accessible name...', 'Explain why...') with no executable markup examples in the body (examples are deferred to the reference).

2 / 3

Workflow Clarity

The Check -> Fix -> Explain -> Code Review sections imply a loose sequence for this simple single-task skill, but there is no explicit verification or validation checkpoint; the Code Review section only vaguely mentions noting 'how to verify the fix'.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md' for full implementation details, code examples, and framework-specific guidance), and that file exists with the expected detail, matching the well-signaled one-level-deep anchor.

3 / 3

Total

9

/

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 provides an explicit use-when trigger and a list of concrete review actions, but its capability statement is awkwardly phrased and its triggers lean technical rather than natural. It answers what and when without being clearly distinctive from sibling accessibility skills.

Suggestions

Rewrite the 'what' as a direct third-person capability statement (e.g., 'Ensures toggle fields (checkboxes, radio buttons, switches) have accessible names') instead of embedding the capitalized rule title as a sentence fragment.

Add natural user-facing trigger terms such as 'checkbox label', 'switch accessibility', or 'make this toggle accessible' alongside the existing technical framing.

Narrow the broad 'reviewing rendered HTML, interactive components, or design-system patterns' trigger to reduce overlap with general accessibility skills and sharpen distinctiveness.

DimensionReasoningScore

Specificity

Names the domain ('accessible names for toggle fields') and lists concrete inspection actions ('inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but those actions are generic accessibility-review steps rather than the skill's actual capability, which is only implied.

2 / 3

Completeness

It has an explicit 'Use when' clause and describes inspection actions, answering both what and when, but the 'what' is weakened by embedding the capitalized rule title as a sentence fragment ('related to Provide accessible names for toggle fields') rather than stating the capability directly.

2 / 3

Trigger Term Quality

Includes relevant terms like 'toggle fields', 'accessible names', and 'screen-reader output', but the triggers lean technical ('reviewing rendered HTML, interactive components, or design-system patterns') and miss natural user phrasings such as 'checkbox label', 'switch accessibility', or 'make this toggle accessible'.

2 / 3

Distinctiveness Conflict Risk

The 'accessible names for toggle fields' niche is fairly specific, but the broad 'reviewing rendered HTML, interactive components, or design-system patterns' trigger could overlap with other accessibility review skills, so it is not cleanly distinctive.

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.