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

50%

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

65%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 compact, well-organized instruction skill: it gives concrete detection criteria and three concrete fix patterns, and correctly pushes code examples into a real one-level-deep reference file. The main gaps are duplicated rationale between the intro and 'Explain' section, and a generic verification pointer in the Code Review section that never names an actual tool or validation step.

Suggestions

Name a concrete verification step in the Code Review section — e.g., 'run axe DevTools or the browser's accessibility inspector and confirm the field no longer reports a missing accessible name' — instead of the generic 'browser accessibility tooling'.

Merge the intro paragraph and the 'Explain' section: both cover screen-reader announcement behavior and Dragon voice-control matching, so keep the detail once and let the intro be one or two sentences.

Dimension	Reasoning	Score
Conciseness	The body is mostly tight and well-sectioned, but the intro paragraph and the 'Explain' section duplicate each other (screen readers announce the name on focus, Dragon users need the name to match visible text), and 'Quick Reference' restates the 'Check' criteria. This fits 'Mostly efficient but includes some unnecessary explanation or could be tightened'; it is not 4 because the duplicated VoiceOver/NVDA/Dragon sentences span two sections.	3 / 5
Actionability	Concrete guidance throughout: three explicit acceptance criteria in 'Check' and copy-paste-shaped fixes in 'Fix' ("<label for='input-id'>Label text</label>", "aria-label='Search'", "aria-labelledby='label-element-id'"). It is not 5 because the 'Code Review' section stays generic ('verify the fix with browser accessibility tooling' names no specific tool or command) and no example markup appears in the body itself.	4 / 5
Workflow Clarity	Check → Fix → Explain → Code Review is a coherent review sequence, but verification is only implicit: the body says to 'note how to verify the fix with browser accessibility tooling' without naming a tool (e.g., axe DevTools) or a concrete validation step. This matches 'Steps listed but validation gaps'; it is not 4 because no checkpoint is actually specified, only gestured at.	3 / 5
Progressive Disclosure	The body is a ~45-line, well-sectioned overview that appropriately keeps code examples and framework guidance in a single one-level-deep reference ("For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`"), and that file exists with matching content. This matches the simple-skill case: clear overview, well-signaled single reference, easy navigation.	5 / 5
	Total	15 / 20 Passed

Description

36%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 defines a clear trigger scope via an explicit element and ARIA-role enumeration, but it never states what the skill does, and the sentence is malformed ('Use when applies to all...'). It also omits the most natural trigger vocabulary for the task — labels, accessible names, screen readers, WCAG. It functions as a scope filter rather than a description of a capability.

Suggestions

State the 'what' alongside the 'when', e.g.: 'Audit form inputs for accessible names and fix unlabeled fields. Use when reviewing markup that contains <input>, <textarea>, <select>, or ARIA textbox/combobox/spinbutton/searchbox/listbox widgets.'

Add the natural trigger vocabulary users would actually say — 'label', 'accessible name', 'form fields', 'screen reader', 'WCAG 4.1.2' — so the skill surfaces for accessibility-review requests, not only when raw element names appear.

Fix the garbled grammar ('Use when applies to all...') and reduce the exhaustive role list to the common phrasing (e.g., 'custom form widgets with textbox, combobox, or listbox roles') so the sentence reads as a description, not a scope dump.

Dimension	Reasoning	Score
Specificity	The description enumerates a concrete domain ("all `<input>` (except type=hidden), `<textarea>`, `<select>`, and custom form widgets using role=textbox, role=combobox...") but states no action whatsoever — it never says the skill ensures accessible names or labels inputs. This matches 'Names the domain but actions are minimal or generic'; it is not 3 because not even one concrete action is given.	2 / 5
Completeness	Only a 'when' is present ("Use when applies to all `<input>`...") and it is grammatically garbled; the 'what' — checking/fixing accessible names on form inputs — is entirely missing. This matches 'only when is present without what'; it is not 3 because the what is not weakly implied but absent.	2 / 5
Trigger Term Quality	It includes relevant technical keywords users doing accessibility work would say (`<input>`, `<textarea>`, `<select>`, role=textbox, role=combobox, role=listbox), but misses the most natural trigger phrases for this skill: 'label', 'accessible name', 'form label', 'screen reader', 'WCAG'. This fits 'Some relevant keywords but missing common variations or synonyms'; not 4 because the core natural terms are absent.	3 / 5
Distinctiveness Conflict Risk	The specific element/role enumeration makes it fairly narrow, but it overlaps with sibling ARIA-name rules (e.g., a select or combobox accessible-name rule would also fire here), and without mentioning 'accessible name' or 'label' its purpose is ambiguous against related accessibility skills. Best fits 'Somewhat specific but could still overlap with similar skills'; not 4 because the overlap with closely related ARIA rules is more than minor.	3 / 5
	Total	10 / 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: 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.