check-accessibility

Check and verify accessibility compliance for Spark UI components. Use when the user wants to test accessibility, verify WCAG compliance, or fix accessibility issues.

Quality

70%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.cursor/skills/check-accessibility/SKILL.md

Quality

Discovery

89%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a solid description that clearly communicates both purpose and trigger conditions, with good natural keywords. Its main weakness is that the capability actions are somewhat general ('check', 'verify', 'fix') rather than listing specific concrete accessibility testing actions. Adding more specific actions would strengthen the description.

Suggestions

Add more specific concrete actions such as 'run automated a11y audits, check color contrast ratios, verify ARIA attributes, test keyboard navigation, validate screen reader compatibility' to improve specificity.

Dimension	Reasoning	Score
Specificity	Names the domain (accessibility compliance for Spark UI components) and some actions (check, verify, fix), but doesn't list specific concrete actions like 'run axe audits, check color contrast ratios, verify ARIA attributes, test keyboard navigation'.	2 / 3
Completeness	Clearly answers both what ('Check and verify accessibility compliance for Spark UI components') and when ('Use when the user wants to test accessibility, verify WCAG compliance, or fix accessibility issues') with explicit trigger guidance.	3 / 3
Trigger Term Quality	Includes strong natural trigger terms: 'accessibility', 'WCAG compliance', 'accessibility issues', 'Spark UI components'. These are terms users would naturally use when seeking this functionality.	3 / 3
Distinctiveness Conflict Risk	Highly distinctive by combining accessibility compliance with a specific component library (Spark UI). The niche of accessibility testing for a named design system is unlikely to conflict with other skills.	3 / 3
	Total	11 / 12 Passed

Implementation

50%

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

The skill has a solid foundation with concrete, executable test commands for automated accessibility testing, but is weakened by vague checklist-style sections that describe rather than instruct. The workflow reads as a categorized list rather than a clear sequential process with validation loops. Trimming generic accessibility knowledge Claude already has and adding a concrete fix-and-verify workflow would significantly improve it.

Suggestions

Replace the vague 'Fix Issues' and 'Manual Checks' sections with a concrete workflow: run tests → read failure output → apply specific fix patterns (with code examples) → re-run tests to verify.

Remove or drastically shorten 'Common Accessibility Requirements' since Claude already knows WCAG AA basics—instead, link to the referenced accessibility-standards.md for project-specific requirements.

Add a concrete example of interpreting axe-core test output and applying a fix, e.g., showing a failing test result and the corresponding ARIA attribute fix in JSX.

Dimension	Reasoning	Score
Conciseness	Mostly efficient but includes some unnecessary content. The 'Manual Checks' and 'Common Accessibility Requirements' sections list things Claude already knows about accessibility. The 'Fix Issues' section is vague and redundant with the requirements section. The automated testing section is well-targeted with specific commands.	2 / 3
Actionability	The automated testing commands are concrete and executable, which is good. However, sections 2, 3, and 5 are vague checklists without specific code examples or concrete guidance—'Add missing ARIA attributes' and 'Fix keyboard navigation' are not actionable instructions.	2 / 3
Workflow Clarity	Steps are numbered but the workflow lacks validation checkpoints and feedback loops. There's no explicit sequence like 'run tests → identify failures → fix specific issues → re-run tests to verify.' The numbered steps read more like categories than a sequential workflow.	2 / 3
Progressive Disclosure	References `.cursor/rules/accessibility-standards.md` for detailed standards, which is good progressive disclosure. However, the inline content includes material that could be offloaded (common requirements, testing tools list), and there's no bundle to verify the referenced file exists.	2 / 3
	Total	8 / 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: leboncoin/spark-web
Commit: 76a3678

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