Design, implement, and audit inclusive digital products using WCAG 2.2 Level AA
68
68%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Quality
Discovery
57%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 establishes a clear niche around accessibility and WCAG compliance, which makes it distinctive. However, it lacks an explicit 'Use when...' clause with natural trigger terms users would say, and the listed actions could be more concrete (e.g., specifying what auditing or implementing entails). Adding common accessibility-related trigger terms and explicit usage conditions would significantly improve skill selection accuracy.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks about accessibility, screen readers, WCAG compliance, keyboard navigation, or making a website/app accessible.'
Include more natural trigger terms users would say, such as 'a11y', 'screen reader support', 'alt text', 'keyboard navigation', 'ADA compliance', 'color contrast'.
Make actions more concrete—e.g., instead of 'audit inclusive digital products', specify 'check color contrast ratios, validate heading hierarchy, review focus order, and generate accessibility audit reports'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (accessibility/WCAG) and some actions ('design, implement, audit', 'generate semantic ARIA', 'accessibility traits'), but the actions are somewhat broad and not fully concrete—e.g., 'audit inclusive digital products' is vague about what auditing entails specifically. | 2 / 3 |
Completeness | The 'what' is partially addressed (design, implement, audit with WCAG standards, generate ARIA/accessibility traits), and there is a partial 'when' implied by 'Use this skill to generate semantic ARIA...', but there is no explicit 'Use when...' clause describing the triggering conditions or user scenarios. | 2 / 3 |
Trigger Term Quality | Includes relevant keywords like 'WCAG 2.2', 'ARIA', 'accessibility', 'iOS/Android', 'semantic', but misses common user-facing trigger terms like 'screen reader', 'a11y', 'alt text', 'keyboard navigation', 'accessible', or 'ADA compliance' that users would naturally say. | 2 / 3 |
Distinctiveness Conflict Risk | The focus on WCAG 2.2 Level AA, ARIA, and accessibility traits for both Web and Native platforms creates a clear, distinct niche that is unlikely to conflict with other skills. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, actionable accessibility skill with excellent cross-platform code examples and a useful mapping table. Its main weaknesses are some unnecessary conceptual explanation (POUR principles, accessibility tree definitions) that Claude already knows, and the lack of explicit validation/testing steps in the workflow. The content would benefit from being trimmed and split into a concise overview with references to platform-specific detail files.
Suggestions
Remove or drastically shorten the 'Core Concepts' section—Claude already understands POUR, the accessibility tree, and focus management. Keep only project-specific conventions.
Add explicit validation steps to the workflow, such as 'Run axe-core or Lighthouse audit' after implementation and 'Test with VoiceOver/TalkBack' before marking complete.
Split platform-specific examples and the cross-platform mapping table into separate referenced files (e.g., WEB_A11Y.md, IOS_A11Y.md, ANDROID_A11Y.md) to keep the main skill lean.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The 'Core Concepts' section explains POUR principles and the accessibility tree, which Claude already knows well. The 'When to Use' section is somewhat redundant given the description. However, the cross-platform mapping table and examples are efficient and information-dense. | 2 / 3 |
Actionability | Provides fully executable code examples across three platforms (Web HTML, SwiftUI, Jetpack Compose), a concrete cross-platform mapping table with specific API calls, specific numeric thresholds (4.5:1 contrast, 24x24px targets), and a practical checklist. The examples are copy-paste ready. | 3 / 3 |
Workflow Clarity | The 5-step process provides a reasonable sequence for implementing accessibility, but lacks validation checkpoints. For an audit workflow, there's no explicit 'test with screen reader' or 'run automated checker' verification step. Given that accessibility implementation can introduce subtle errors, the absence of a feedback loop caps this at 2. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and headers, but it's fairly long and monolithic. The cross-platform mapping table, detailed examples for three platforms, anti-patterns, and checklist could be split into referenced files. References to external docs are present but no internal file references for deeper content. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 10 / 11 Passed | |
Reviewed
Table of Contents