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.

Quality

60%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/aria-toggle-field-name/SKILL.md

Quality

Content

57%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 with exemplary progressive disclosure (concise body, one clearly-signaled reference file that exists and carries the code examples), held back by redundant sections, vague detection/verification steps, and the absence of any concrete example or checking method in the body itself.

Suggestions

Add a concrete detection step to Check — e.g., inspect the element in the browser accessibility tree or run axe/Lighthouse — instead of the abstract 'check for a valid accessible name'.

Merge the Quick Reference bullets into Check/Fix (or vice versa) to remove duplication, and drop the opening paragraph explaining why labels matter.

Include one minimal before/after markup snippet (missing label vs. label/aria-label fix) so the body is actionable without opening the reference.

Dimension	Reasoning	Score
Conciseness	The body is short but padded: the opening paragraph explains why labels matter (a concept Claude already knows), the Quick Reference bullets largely restate the Check and Fix sections, and the Code Review section re-paraphrases the description. It could be tightened by merging these overlapping sections.	3 / 5
Actionability	The Fix section names concrete techniques ('a label element, aria-label, or aria-labelledby'), but Check gives no detection method (accessibility tree, axe, devtools), no markup example appears in the body, and verification guidance ('browser accessibility tooling') stays vague.	3 / 5
Workflow Clarity	The Check → Fix → Explain → Code Review section order implies a workflow, but verification is a passing mention rather than an explicit checkpoint, and no concrete detection or validation steps are sequenced.	3 / 5
Progressive Disclosure	Clean split verified against the actual bundle: a concise overview in SKILL.md with details and code examples one level deep in references/rule.md, clearly signaled by 'For full implementation details... see references/rule.md'.	5 / 5
	Total	14 / 20 Passed

Description

63%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 serviceable description with an explicit 'Use when' trigger and several concrete inspection actions, weakened by an awkwardly embedded rule name, missing natural synonyms (checkbox, radio, switch, label), and a broad trigger clause that risks overlap with other accessibility skills.

Suggestions

Add natural trigger synonyms users actually say — checkbox, radio button, switch, toggle, label, screen reader — to the 'Use when' clause.

Replace the awkward 'related to Provide accessible names for toggle fields' phrasing with a direct statement of the skill's purpose, e.g., 'Check that checkboxes, radio buttons, and switches have valid accessible names'.

Narrow the trigger context (e.g., 'when reviewing form controls or toggle components for accessibility') to reduce overlap with other accessibility/design-system skills.

Dimension	Reasoning	Score
Specificity	The description lists several concrete inspection actions ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output'), but the awkward 'related to Provide accessible names for toggle fields' phrasing leaves the core capability stated imperfectly, so it falls short of comprehensive anchor 5.	4 / 5
Completeness	Both what (check native semantics, inspect keyboard behavior, focus flow, accessible names) and when ('Use when reviewing rendered HTML, interactive components, or design-system patterns') are present, but the when-clause could be more specific about the toggle controls involved and the core purpose is awkwardly embedded.	4 / 5
Trigger Term Quality	Relevant keywords exist ('rendered HTML', 'interactive components', 'design-system patterns', 'toggle fields', 'accessible names'), but common natural terms users would actually say — checkbox, radio button, switch, label, screen reader — are missing from the trigger clause.	3 / 5
Distinctiveness Conflict Risk	'Reviewing rendered HTML, interactive components, or design-system patterns' is broad enough to overlap with sibling accessibility and design-system rule skills; only 'toggle fields' meaningfully narrows the trigger.	3 / 5
	Total	14 / 20 Passed

Validation

93%

Warnings & errors only

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

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/aria-toggle-field-name/SKILL.md
Commit: 7bfd868

Reviewed: 1 day ago

Table of Contents

Discovery Implementation Validation

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.