CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

accordion-accessibility

Use when reviewing templates, rendered HTML, or shared components related to Make accordions keyboard navigable. Validate the final browser-facing markup, not just the source framework abstraction.

52

Quality

65%

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/accordion-accessibility/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

53%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 a real and appropriate one-level-deep reference file, but it suffers from triple redundancy of the ARIA attribute checklist, an unnecessary conceptual opener, and no executable inline example or post-fix validation step. Actionability and workflow clarity sit mid-scale because the concrete pattern is fully deferred to the reference.

Suggestions

De-duplicate the ARIA attribute list: state it once (e.g., in Quick Reference) and have Check/Fix reference it or show a minimal inline correct-markup snippet instead of restating it.

Add a feedback loop to the workflow: after applying fixes, re-verify the rendered markup against the Check criteria (e.g., "Re-run the Check on the re-rendered output; confirm keyboard trap-free navigation") rather than ending at Fix.

Replace the conceptual opener about why poor accordions trap users with actionable content, and link each body section to the relevant part of references/rule.md for section-level navigation.

DimensionReasoningScore

Conciseness

The body is short and mostly efficient, but the button/aria-expanded/aria-controls attribute list is repeated nearly verbatim across "Quick Reference", "Check", and "Fix", and the opener "Poorly implemented accordions trap keyboard users and leave screen reader users unable to understand or navigate collapsed content sections" explains a concept Claude already knows. It is above anchor 2 (not heavily padded) but not efficiently trimmed enough for anchor 4.

3 / 5

Actionability

Concrete attribute- and key-level specifics are given ("aria-expanded", "aria-controls", "Enter, Space, arrows", "heading elements"), but the body contains no code or commands — everything executable is deferred to references/rule.md — and phrases like "proper keyboard navigation" and "and keyboard support" are vague. This matches anchor 3 (some concrete guidance but incomplete) rather than anchor 4's mostly-executable bar.

3 / 5

Workflow Clarity

A rough sequence is present (Quick Reference → Check → Fix → Explain → Code Review), but there are no validation checkpoints: no re-check step after applying fixes and no feedback loop confirming the fixed markup passes the rule. Not below anchor 3 since this is a review skill, not a destructive or batch operation, and not anchor 4 because checkpoints are missing or only implicit.

3 / 5

Progressive Disclosure

The structure is good: a thin overview in SKILL.md with a single one-level-deep reference (references/rule.md, verified to exist and contain the promised code examples and framework guidance), clearly signaled at the end. It falls short of anchor 5 because the pointer is a single generic end-of-file note rather than section-mapped navigation, and the "Check" section's "exact elements, attributes, and routes" phrasing in Code Review is not tied to where the detailed pattern lives.

4 / 5

Total

13

/

20

Passed

Description

62%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 answers both when and what with a clearly signaled trigger clause and a distinctive accordion-accessibility niche, but it is not comprehensive: the natural vocabulary (ARIA, screen reader, accessibility, collapsible) is absent and the rule-title splice "related to Make accordions keyboard navigable" reads awkwardly as a capability statement.

Suggestions

Rewrite the splice "related to Make accordions keyboard navigable" into a natural capability statement, e.g., "Review templates, rendered HTML, or shared components to ensure accordion widgets are keyboard navigable..."

Add natural trigger synonyms users would actually say — "ARIA", "screen reader", "accessibility", "collapsible sections" — to improve trigger term coverage and searchability.

State the concrete capability actions explicitly (validate button triggers, aria-expanded, aria-controls, arrow-key navigation) rather than deferring all specificity to the body.

DimensionReasoningScore

Specificity

The description names its domain ("accordions keyboard navigable", browser-facing markup) and one to two concrete actions ("reviewing templates, rendered HTML, or shared components", "Validate the final browser-facing markup"), but is not a comprehensive list of specific actions. It is above the score-2 anchor because the actions it names are concrete rather than generic.

3 / 5

Completeness

Both are present: an explicit "Use when reviewing templates, rendered HTML, or shared components..." trigger and a what-statement ("Validate the final browser-facing markup, not just the source framework abstraction"). It falls short of anchor 5 because the phrase "related to Make accordions keyboard navigable" is a garbled rule-title splice that muddies the capability statement rather than stating it concretely.

4 / 5

Trigger Term Quality

Relevant keywords are present ("accordions", "keyboard navigable", "templates", "rendered HTML", "shared components", "markup"), but common natural variations are missing — "ARIA", "screen reader", "accessibility", "collapsible". It does not reach anchor 4's good coverage of natural terms.

3 / 5

Distinctiveness Conflict Risk

The accordion/keyboard-navigability niche is clear and distinct, but the broad trigger surface ("reviewing templates, rendered HTML, or shared components") overlaps with sibling frontend accessibility rules that share the same trigger phrasing. Above anchor 3 because the accordion keyword provides a distinct hook; below anchor 5 due to that shared surface.

4 / 5

Total

14

/

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

Path

skills/accordion-accessibility/SKILL.md

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.