aria-required-children

Use when applies to custom ARIA widgets using composite roles: tablist, list, listbox, menu, menubar, tree, treegrid, grid, rowgroup, row, radiogroup. Use when reviewing components built with div/span elements that replace native HTML list, select, or nav elements.

Quality

64%

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-required-children/SKILL.md

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 body is well-structured with a clean progressive-disclosure split to a real reference file, but it leans on concept re-explanation, defers executable markup to the reference, and presents validation implicitly rather than as an explicit feedback loop.

Suggestions

Move or compress the "Explain" section's restatement of WAI-ARIA required-owned-elements theory, keeping only the distinction from aria-required-parent that Claude would not infer.

Add a short inline ✅/❌ HTML snippet for the most common case (tablist→tab) so the body is immediately actionable without forcing a file hop.

Insert an explicit verification checkpoint after Fix, e.g. "Re-check with an accessibility scanner (axe) or screen reader to confirm the container now enumerates its children".

Dimension	Reasoning	Score
Conciseness	The body is mostly lean and well-organized into Check/Fix/Explain/Code Review, but the "Explain" section re-explains WAI-ARIA "required owned elements" — a concept Claude already knows — and the intro carries some justificatory padding ("Screen readers like NVDA and VoiceOver...") that could be tightened.	2 / 3
Actionability	Concrete role-to-child mappings and a numbered three-step Fix with specific remedies (add role='tab', role='none'/'presentation' on wrappers, prefer <ul>/<li>) are provided, but the executable HTML markup examples live only in the reference, so the body guidance is instructional rather than copy-paste ready.	2 / 3
Workflow Clarity	A logical Check → Fix → Code Review sequence is present and the Code Review section mentions verifying "with browser accessibility tooling or assistive tech", but validation checkpoints are implicit — the Check doubles as validation — and there is no explicit verify-after-fix feedback loop.	2 / 3
Progressive Disclosure	A concise overview body defers full implementation details, code examples, and framework-specific guidance to a single clearly signaled one-level-deep reference (references/rule.md) that is a real file containing the deferred examples, giving easy navigation.	3 / 3
	Total	9 / 12 Passed

Description

72%

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 is specific and distinctive with strong, natural trigger terms and explicit "when" guidance, but it never states the concrete action the skill performs, leaving the "what" implicit and capping completeness.

Suggestions

Lead with an explicit action verb stating what the skill does, e.g. "Validates that ARIA composite container roles contain their required owned child roles and fixes invalid nesting."

Trim the awkward "Use when applies to" phrasing into a single clear trigger clause to improve readability without losing keywords.

Surface the core remediation (add required child roles, use role='none' on wrappers, prefer native HTML) briefly so the description conveys capability, not just applicability.

Dimension	Reasoning	Score
Specificity	Names the concrete domain and specific composite roles ("tablist, list, listbox, menu, menubar, tree, treegrid, grid, rowgroup, row, radiogroup"; "div/span elements that replace native HTML list, select, or nav"), but the actions are implied via "applies to" and "reviewing" rather than enumerated as concrete verbs, so it is not comprehensive on what the skill does.	2 / 3
Completeness	The "when" is explicit via two "Use when" clauses, but the "what does this do" (e.g., validate/ensure required child roles) is only implied through "applies to" and never stated as an explicit action, so what-and-when is not both clearly answered.	2 / 3
Trigger Term Quality	Covers the natural terms developers actually use for this domain — "custom ARIA widgets", the individual role names (tablist, menu, tree), "div/span elements", and "native HTML list, select, or nav" — with explicit "Use when" trigger framing.	3 / 3
Distinctiveness Conflict Risk	A highly specific niche anchored on an enumerated list of composite ARIA roles and div/span-replacement scenarios, making it clearly distinguishable and unlikely to trigger the wrong skill.	3 / 3
	Total	10 / 12 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-required-children/SKILL.md
Commit: 48405aa

Reviewed: about 8 hours 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.