aria-input-field-name

Use when applies to all `<input>` (except type=hidden), `<textarea>`, `<select>`, and custom form widgets using role=textbox, role=combobox, role=spinbutton, role=searchbox, or role=listbox.

Quality

53%

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-input-field-name/SKILL.md

Quality

Content

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

The body is a well-organized, largely actionable overview with a clean one-level reference, scoring well on actionability, workflow clarity, and structure. Its main weakness is conciseness: assistive-tech behavior and the accessible-name computation order are explained in the body and again in the reference.

Suggestions

Remove the "Explain" section's restatement of the accessible-name computation order and WCAG rationale from the body since references/rule.md already covers it; keep only a one-line pointer.

Tighten the intro to drop the VoiceOver/NVDA/Dragon behavior Claude already knows, retaining only the user-impact framing needed to prioritize the rule.

Promote verification into an explicit numbered step in the body workflow (e.g., a "Verify" step referencing axe/Lighthouse and the accessibility tree) rather than leaving it implicit.

Dimension	Reasoning	Score
Conciseness	The Check and Fix sections are tight and useful, but the intro and "Explain" sections re-explain assistive-tech behavior (VoiceOver, NVDA, Dragon) and the accessible-name computation order that Claude already knows, and the computation order is duplicated in references/rule.md.	3 / 5
Actionability	Check gives three concrete pass/fail conditions and Fix gives three numbered methods with inline attribute examples (label for/id, aria-label='Search', aria-labelledby), though full copy-paste HTML examples are deferred to references/rule.md and the Code Review section stays somewhat abstract.	4 / 5
Workflow Clarity	The find → check (three conditions) → flag → fix sequence is clear and numbered for a single-purpose review skill, with verification signaled via browser accessibility tooling; the only gap is that the verify checkpoint is implicit in the body rather than an explicit numbered step.	4 / 5
Progressive Disclosure	The body is a well-sectioned overview with a clearly signaled one-level reference ("see references/rule.md", verified to exist), but the "Explain" section duplicates the accessible-name computation order and why-it-matters content already in the reference file, a minor split-the-content gap.	4 / 5
	Total	15 / 20 Passed

Description

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

The description functions as a precise scope/trigger clause but omits any statement of what the skill does, leaving the "what" half of completeness unaddressed. Trigger coverage is technically relevant yet misses the most natural user phrasings.

Suggestions

Lead with a concrete action clause before the trigger, e.g. "Checks that every form input has an accessible name. Use when...", so the "what" is explicit.

Add natural-language trigger terms users actually say — "label", "accessible name", "form labels", "screen reader" — alongside the ARIA role list.

Trim the full role enumeration to the most common cases (textbox, combobox, listbox) and defer the exhaustive list to the body to reduce jargon load.

Dimension	Reasoning	Score
Specificity	The description names the domain concretely ("<input>", "<textarea>", "<select>", "role=textbox, role=combobox, role=spinbutton, role=searchbox, role=listbox") but states no concrete actions — it only scopes when the skill applies, with no verb describing what the skill does.	2 / 5
Completeness	Only the "when" is present ("Use when applies to all <input>...") with no "what" — there is no statement of what the skill does, matching the anchor where only the trigger is given without the action.	2 / 5
Trigger Term Quality	It includes relevant technical terms (input, textarea, select, ARIA roles) but leans on jargon-heavy role names and omits the natural phrases users would actually say, such as "label", "accessible name", or "form labels".	3 / 5
Distinctiveness Conflict Risk	It carves a clear niche (accessible naming of form inputs and specific custom-widget roles) with distinct triggers and only minor overlap risk against broader accessibility skills.	4 / 5
	Total	11 / 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-input-field-name/SKILL.md
Commit: 30756a7

Reviewed: 25 days 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.