fixing-accessibility

Audit and fix HTML accessibility issues including ARIA labels, keyboard navigation, focus management, color contrast, and form errors. Use when adding interactive controls, forms, dialogs, or reviewing WCAG compliance.

1.06x

Quality

83%

Does it follow best practices?

Impact

99%

1.06x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Quality

Content

82%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, token-efficient accessibility checklist with concrete rules and copy-paste HTML examples. It lacks explicit post-fix validation feedback loops and could optionally split the nine rule categories into a reference file, but otherwise scores strongly across all dimensions.

Suggestions

Add an explicit validation/re-check step to the review workflow (e.g., after applying a fix, re-scan the file to confirm the violation is resolved) to raise workflow_clarity.

Provide a short code example for each high/critical category (e.g., focus trapping, aria-live announcements) rather than only the three common fixes, to push actionability higher.

Consider moving the detailed per-category rules into a references/ file linked from the SKILL.md overview to improve progressive disclosure, keeping the top-level file as a concise index.

Dimension	Reasoning	Score
Conciseness	Lean, imperative rules with no padding or explanations of concepts Claude already knows (no "what is ARIA" or "what is accessibility" prose); every section, including the before/after HTML snippets, earns its place.	5 / 5
Actionability	Concrete directives ("icon-only buttons must have aria-label", "do not use tabindex greater than 0") plus copy-paste-ready HTML before/after examples covering common cases, but not every rule category has a code example and some guidance remains directive rather than executable.	4 / 5
Workflow Clarity	The <file> mode defines a clear review-and-report sequence with a structured output (violations, why it matters, concrete fix) and a prioritized fix order, but there are no explicit validation or feedback-loop checkpoints after a fix is applied.	4 / 5
Progressive Disclosure	Well-organized with clear section headers, a priority table, and nine quick-reference categories in a self-contained file with no external references needed; the inline nine-category checklist is slightly long but appropriately structured for a review skill.	4 / 5
	Total	17 / 20 Passed

Description

83%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, third-person description that clearly conveys both capability and trigger conditions with concrete, natural terms. Its main weakness is a slightly limited action vocabulary and some overlap risk with general frontend work.

Suggestions

Broaden the action verbs beyond "audit and fix" (e.g., "audit, repair, and report on") to increase specificity.

Add common synonyms like "a11y" or "screen-reader compatibility" to strengthen trigger-term coverage.

Tighten the "Use when" clause to anchor more firmly on accessibility intent (e.g., "Use when verifying keyboard, screen-reader, or WCAG compliance") to reduce overlap with generic frontend skills.

Dimension	Reasoning	Score
Specificity	Names the domain and two concrete actions ("Audit and fix HTML accessibility issues") plus a comprehensive enumeration of covered areas (ARIA labels, keyboard navigation, focus management, color contrast, form errors), but the verbs themselves are limited to audit/fix rather than a wider set of distinct operations.	4 / 5
Completeness	Explicitly states what it does ("Audit and fix HTML accessibility issues including ARIA labels, keyboard navigation, focus management, color contrast, and form errors") and when to use it ("Use when adding interactive controls, forms, dialogs, or reviewing WCAG compliance") with concrete trigger phrases.	5 / 5
Trigger Term Quality	Includes natural terms users would say ("forms", "dialogs", "WCAG compliance", "interactive controls", "ARIA") but misses common synonyms such as "a11y" and has no file-extension triggers, so coverage is good rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	The accessibility/WCAG niche is clearly distinct, but triggers like "adding interactive controls, forms, dialogs" are broad enough to overlap with general frontend/UI skills, creating minor conflict risk.	4 / 5
	Total	17 / 20 Passed

Validation

100%

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: ibelick/ui-skills
Path: skills/fixing-accessibility/SKILL.md
Commit: f5dd1de

Reviewed: 5 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.