accessibility-a11y

Implement web accessibility (a11y) best practices following WCAG guidelines to create inclusive, accessible user interfaces.

Quality

22%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Fix and improve this skill with Tessl

tessl review fix ./accessibility-a11y/SKILL.md

Quality

Content

12%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This skill is essentially a generic WCAG cheat sheet that restates widely known accessibility principles Claude already understands. It lacks any executable code examples, concrete patterns, project-specific guidance, or workflow structure. The content would benefit enormously from being condensed to project-specific rules and augmented with actionable code snippets.

Suggestions

Replace abstract bullet points with concrete, executable code examples (e.g., show a complete accessible form component, a proper ARIA live region implementation, or an axe-core test setup).

Remove or drastically condense sections that restate standard WCAG knowledge Claude already knows (semantic HTML basics, color contrast ratios, alt text requirements) and focus on project-specific patterns or non-obvious gotchas.

Add a clear workflow with validation checkpoints, e.g., '1. Implement component → 2. Run axe-core check → 3. Fix violations → 4. Manual screen reader test → 5. Verify in CI pipeline'.

Split detailed reference material (ARIA patterns, testing tools, CSS practices) into separate bundle files and provide a concise overview with links in the main SKILL.md.

Dimension	Reasoning	Score
Conciseness	The skill is extremely verbose and largely restates well-known web accessibility guidelines that Claude already knows. Almost every bullet point (semantic HTML, ARIA roles, color contrast ratios, keyboard navigation) is standard knowledge that doesn't need to be spelled out. The content reads like a WCAG summary rather than adding novel, project-specific guidance.	1 / 3
Actionability	The entire skill consists of abstract guidelines and best-practice bullet points with zero executable code, no concrete examples, no code snippets, and no specific commands. Statements like 'Use aria-label for elements without visible text labels' describe rather than instruct with actionable, copy-paste-ready patterns.	1 / 3
Workflow Clarity	There is a logical structure moving from principles to implementation to testing, and the testing section mentions specific tools and steps. However, there are no explicit validation checkpoints, no sequenced workflow for implementing accessibility in a project, and no feedback loops for catching and fixing issues.	2 / 3
Progressive Disclosure	The content is a monolithic wall of bullet points with no references to external files, no layered structure, and no navigation aids. All content is inline regardless of depth or complexity, and there are no bundle files to support progressive disclosure.	1 / 3
	Total	5 / 12 Passed

Description

32%

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 identifies the correct domain (web accessibility/WCAG) but remains too high-level, reading more like a tagline than a functional skill description. It lacks specific concrete actions, natural trigger terms users would use, and critically omits any 'Use when...' guidance to help Claude know when to select this skill.

Suggestions

Add a 'Use when...' clause with explicit triggers, e.g., 'Use when the user asks about accessibility, a11y, WCAG compliance, screen reader support, ARIA attributes, or keyboard navigation.'

List specific concrete actions such as 'Add ARIA labels, fix color contrast ratios, implement keyboard navigation, write alt text for images, audit HTML for WCAG compliance.'

Include additional natural trigger terms users would say, such as 'screen reader', 'alt text', 'color contrast', 'ADA', 'Section 508', 'focus management', and 'semantic HTML'.

Dimension	Reasoning	Score
Specificity	Names the domain (web accessibility, WCAG) and a general action ('implement best practices', 'create inclusive, accessible user interfaces'), but does not list specific concrete actions like adding ARIA labels, fixing color contrast, implementing keyboard navigation, or writing alt text.	2 / 3
Completeness	Describes what the skill does at a high level but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and the 'what' is also weak, so this scores a 1.	1 / 3
Trigger Term Quality	Includes some relevant keywords like 'accessibility', 'a11y', 'WCAG', and 'accessible', but misses common natural terms users would say such as 'screen reader', 'ARIA', 'alt text', 'keyboard navigation', 'color contrast', or 'ADA compliance'.	2 / 3
Distinctiveness Conflict Risk	The mention of 'a11y', 'WCAG', and 'accessibility' provides some distinctiveness, but the broad phrasing 'create inclusive, accessible user interfaces' could overlap with general UI/UX or frontend development skills.	2 / 3
	Total	7 / 12 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 — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: mindrally/skills
Commit: 05a7130

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