CtrlK
BlogDocsLog inGet started
Tessl Logo

aria-required-parent

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Ensure ARIA roles are contained by required parent roles. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

59

Quality

69%

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-required-parent/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

63%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-structured, brief overview with excellent progressive disclosure to a real reference file. Its weaknesses are redundancy between the Quick Reference, Check, and Code Review sections, and Check/Fix guidance that names no concrete detection tooling or example markup in the body itself.

Suggestions

Merge the Quick Reference bullets into the Check section (or cut them) to remove the restatement of the same nesting rule.

Name a concrete detection method in Check (e.g., axe-core rule list or the DevTools accessibility tree) so the verification step is executable, not just directional.

Inline one minimal before/after snippet (orphaned role="listitem" vs. wrapped in role="list") in Fix so the fix is copy-paste ready without opening the reference.

DimensionReasoningScore

Conciseness

The Quick Reference bullets ("Certain roles (like `listitem`) must be owned by specific parent roles") largely restate the Check section, and the Code Review section repeats the frontmatter description. Mostly efficient, but the redundancy could be tightened into one statement.

3 / 5

Actionability

"Wrap elements with roles that require a specific parent in the appropriate container role (e.g., wrap role="listitem" in role="list")" is concrete, but the Check section gives no method (no axe-core, DevTools accessibility tree, or code snippet in the body). Some concrete guidance, incomplete on the detection side.

3 / 5

Workflow Clarity

A clear sectioned sequence (Quick Reference → Check → Fix → Explain → Code Review) with verification signaled ("note how to verify the fix with browser accessibility tooling"). Simple non-destructive skill; the minor gap is that no specific validation tooling is named in the body itself.

4 / 5

Progressive Disclosure

A short overview body with a single clearly signaled one-level-deep pointer — "For full implementation details, code examples, and framework-specific guidance, see `references/rule.md`" — and the referenced file exists and holds the code examples and verification details. Matches the clear-overview anchor.

5 / 5

Total

15

/

20

Passed

Description

75%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 solid description with an explicit Use-when clause and several concrete review actions. Its main weaknesses are missing natural synonyms (accessibility, a11y), a "what" that relies on the rule title instead of explicit actions, and a template-like opening shared with sibling accessibility skills.

Suggestions

Add natural trigger synonyms such as "accessibility", "a11y", or "ARIA nesting" to broaden keyword coverage.

State the core action explicitly (e.g., "Flags ARIA child roles missing their required parent and wraps them in the correct container") instead of relying on the rule title.

Vary the opening clause so it does not read identically to sibling accessibility skills, reducing conflict risk within the family.

DimensionReasoningScore

Specificity

"Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" lists several concrete review actions, but the core capability leans on the rule title rather than naming explicit remediation actions, so it falls just short of comprehensive coverage.

4 / 5

Completeness

Both are present: an explicit "Use when reviewing rendered HTML, interactive components, or design-system patterns..." trigger and concrete check/inspect actions for the "what". Not a 5 because the "when" is procedural rather than user-intent trigger phrases, and the "what" is partly implied by the rule title.

4 / 5

Trigger Term Quality

Includes natural terms like "rendered HTML", "interactive components", "ARIA roles", "keyboard behavior", and "screen-reader output", but misses common variations users would say such as "accessibility", "a11y", or "aria-required-parent".

4 / 5

Distinctiveness Conflict Risk

Scoped to a specific ARIA nesting rule ("required parent roles") with distinctive accessibility-review triggers, but could overlap with sibling accessibility skills in the same review family that share the "reviewing rendered HTML / interactive components" opening.

4 / 5

Total

16

/

20

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.

Validation — 15 / 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.