modal-accessibility

Use when reviewing rendered HTML, interactive components, or design-system patterns related to Make modal dialogs keyboard accessible. Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output where relevant.

Quality

70%

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/modal-accessibility/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.

The body is a lean overview with excellent progressive disclosure into references/rule.md and concrete attribute-level guidance. It loses points on redundancy across the Check/Fix/Explain sections and on the absence of a sequenced review workflow with verification checkpoints.

Suggestions

Collapse the Quick Reference, Check, Fix, and Explain sections into one non-redundant section, since all four restate the same ARIA/focus/keyboard requirements.

Turn the Check section into an ordered review procedure (e.g. 1. inspect roles/attributes, 2. Tab through to test focus trap, 3. press Escape and verify focus returns to trigger, 4. verify accessible name) with pass/fail criteria.

Name specific verification tooling (e.g. browser DevTools accessibility tree, keyboard-only walkthrough) instead of the generic 'browser accessibility tooling or assistive tech'.

Dimension	Reasoning	Score
Conciseness	The Quick Reference, Check, Fix, and Explain sections each restate the same ARIA/focus/keyboard requirements in slightly different words, and 'Explain' is meta-filler — noticeable repetition, though the body is short and free of background-concept padding.	3 / 5
Actionability	Gives concrete, exact guidance — "Use role='dialog' and aria-modal='true'", "aria-labelledby pointing to the modal title", "Close on Escape key press and return focus to trigger element" — with only minor gaps (no inline code sample, verification tooling named but unspecified).	4 / 5
Workflow Clarity	'Verify modals have proper ARIA roles, focus trapping, keyboard dismissal (Escape), and return focus on close' lists checks but provides no ordered review sequence or pass/fail checkpoints; the structure is sectioned by verb (Check/Fix/Explain) rather than sequenced steps.	3 / 5
Progressive Disclosure	A concise overview body with a single, clearly signaled, one-level-deep reference ('For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — verified to exist), with implementation details appropriately split out.	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.

The description explicitly covers both what the skill does and when to use it, with a solid set of concrete review actions and natural trigger terms. Its main weakness is the ungrammatical when-clause ('related to Make modal dialogs keyboard accessible'), which hurts clarity and keeps it just below top scores.

Suggestions

Fix the grammar of the when-clause, e.g. 'Use when reviewing rendered HTML, interactive components, or design-system patterns to make modal dialogs keyboard accessible.'

Add common user synonyms such as 'dialog', 'popup', 'focus trap', or 'a11y/accessibility' to broaden natural trigger coverage.

Dimension	Reasoning	Score
Specificity	Lists several concrete review actions — 'Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output' — but the garbled trigger tail ('related to Make modal dialogs keyboard accessible') muddies the core action, leaving minor gaps versus comprehensive coverage.	4 / 5
Completeness	Both 'what' ('Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output') and 'when' ('Use when reviewing rendered HTML...') are explicit, but the when-clause's grammar makes it less crisp than a level-5 trigger phrase.	4 / 5
Trigger Term Quality	Includes natural terms users would say — 'rendered HTML', 'interactive components', 'modal dialogs', 'keyboard', 'screen-reader' — but misses common synonyms like 'popup', 'dialog', 'a11y', or 'accessibility review'.	4 / 5
Distinctiveness Conflict Risk	'Make modal dialogs keyboard accessible' is a clear niche with distinct triggers, but 'reviewing rendered HTML, interactive components, or design-system patterns' is broad enough for minor overlap with sibling accessibility or design-system review skills.	4 / 5
	Total	16 / 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/modal-accessibility/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.