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

76%

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.

A well-structured overview that delegates implementation detail appropriately to a real one-level reference, with concrete actionable Quick Reference bullets. Weaker on conciseness (rhetorical opener and restated sections) and workflow clarity (no explicit validation checkpoints).

Suggestions

Cut the rhetorical opening sentence about modals being "invisible traps" — Claude already understands the impact of inaccessible modals.

De-duplicate the Check/Fix/Explain/Code Review sections, which restate the same ARIA/focus/keyboard points in different framings; merge or trim to reduce repetition.

Add an explicit validation checkpoint in the workflow (e.g. a numbered "Verify" step pointing to the manual/automated checks in references/rule.md) so the fix → verify loop is unambiguous.

Dimension	Reasoning	Score
Conciseness	Mostly efficient, but the opening rhetorical sentence ("modal dialogs are invisible traps for keyboard users—they can't navigate, can't escape...") explains a concept Claude already knows, and the Check/Fix/Explain/Code Review sections restate the same ARIA/focus/keyboard points with noticeable redundancy.	3 / 5
Actionability	The Quick Reference bullets give concrete, actionable attributes (role='dialog', aria-modal='true', aria-labelledby, Escape close, focus return), and the Code Review section specifies what to flag; minor gap is the absence of any inline code (delegated to references/rule.md).	4 / 5
Workflow Clarity	A rough Check → Fix → Explain → Code Review sequence is present, but there are no numbered steps or explicit validation checkpoints; verification of the fix is only implicitly referenced rather than stated as a checkpoint.	3 / 5
Progressive Disclosure	The body is a well-organized overview (Quick Reference, Check, Fix, Explain, Code Review) with a clearly signaled one-level-deep reference — "see references/rule.md" — and that bundle file exists, keeping detail out of the overview.	5 / 5
	Total	15 / 20 Passed

Description

88%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 strong description that clearly states both the trigger conditions and the concrete review actions, with comprehensive capability coverage. Minor overlap risk from the broad opening clause and a few missing trigger synonyms.

Suggestions

Tighten the trigger clause to lead with the modal-specific context (e.g. "Use when making modal dialogs keyboard accessible") to reduce overlap with general accessibility/frontend review skills.

Add a common natural synonym such as "focus trap" or "modal accessibility" to broaden trigger-term match with how users phrase the request.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — "Check native semantics first, then inspect keyboard behavior, focus flow, accessible names, and screen-reader output" — giving comprehensive coverage of the review task.	5 / 5
Completeness	Explicitly answers both what (check semantics, inspect keyboard behavior, focus flow, accessible names, screen-reader output) and when ("Use when reviewing rendered HTML, interactive components, or design-system patterns related to Make modal dialogs keyboard accessible") with concrete trigger phrases.	5 / 5
Trigger Term Quality	Good natural-term coverage ("reviewing rendered HTML", "interactive components", "design-system patterns", "modal dialogs", "keyboard accessible"), though a few common synonyms a user might say (e.g. "modal accessibility", "focus trap") are missing.	4 / 5
Distinctiveness Conflict Risk	The narrow modal-keyboard-accessibility niche is distinct, but the broad opening "reviewing rendered HTML, interactive components, or design-system patterns" creates minor overlap risk with general accessibility or frontend review skills.	4 / 5
	Total	18 / 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: 30756a7

Reviewed: 26 days 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.