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

80%

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 ./.cursor/skills/check-accessibility/SKILL.md

Quality

Content

68%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-organized, largely executable skill body whose automated-testing instructions are the highlight. The main weaknesses are the missing verify-after-fix loop in the workflow and generic accessibility checklists that either need concrete steps or should be moved into a bundled standards reference.

Suggestions

Add an explicit validation step to the workflow, e.g. after 'Fix Issues': re-run `npm run test:a11y -- <component>` and only consider the issue resolved when the report is clean.

Move the generic WCAG requirements checklist (section 3) into a bundled reference file next to the standards pointer, keeping only the project-specific deltas inline in SKILL.md.

Replace vague fix guidance (e.g. 'Improve focus management') with concrete patterns such as expected focus behavior for the common Spark components (tabs, dialogs, menus).

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient: a tight command block, short checklists, and no concept tutorials. It dips below a 5 because sections like "Common Accessibility Requirements" ("Color contrast meets WCAG AA (4.5:1 for text)") and "Fix Issues" restate accessibility knowledge Claude already has and could be trimmed or delegated to the referenced standards doc.	4 / 5
Actionability	The automated-testing section is copy-paste ready ("npm run test:a11y -- tabs") and even explains component-name matching against e2e/a11y/routes/components.ts. Not a 5 because the Manual Checks and Fix Issues sections give direction ("Improve focus management", "Add missing ARIA attributes") without concrete verification steps or examples.	4 / 5
Workflow Clarity	The numbered flow (automated testing → manual checks → fix issues) is a clear sequence, but there is no validation checkpoint: nothing says to re-run npm run test:a11y after applying fixes to confirm the violations are resolved. That implicit feedback loop matches the anchor "steps listed but validation gaps"; not a 4 because the re-test checkpoint is genuinely missing rather than minor.	3 / 5
Progressive Disclosure	The body is well organized into clear sections with no monolithic wall of text, and there are no nested references. Not a 5 because the only deep pointer goes outside the skill bundle to a repo path (.cursor/rules/accessibility-standards.md) rather than a properly bundled reference file, and the generic WCAG requirements inlined in the body are content that could live in that reference.	4 / 5
	Total	15 / 20 Passed

Description

82%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: it clearly states what the skill does and gives an explicit, well-phrased 'Use when' clause with concrete triggers. The main gap is specificity — the actions are somewhat generic — and it omits the natural synonym "a11y" that the body itself treats as a trigger.

Dimension	Reasoning	Score
Specificity	"Check and verify accessibility compliance for Spark UI components" names the domain (Spark UI components, WCAG) with 1-2 actions, but "check" and "verify" are near-synonymous and no more concrete operations are listed. Not a 2 because the domain is explicitly named with actionable verbs; not a 4 because there is no list of several distinct specific actions.	3 / 5
Completeness	It explicitly 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 three concrete trigger phrases. Not a 4 because the 'when' clause is already explicit and specific rather than weakly implied.	5 / 5
Trigger Term Quality	Natural phrases like "test accessibility", "verify WCAG compliance", and "fix accessibility issues" give good keyword coverage. Not a 5 because common synonyms such as "a11y" (which the body itself lists as a trigger) and screen-reader terminology are missing from the description.	4 / 5
Distinctiveness Conflict Risk	The Spark UI component scope combined with WCAG-specific triggers carves out a clear niche with minimal conflict risk against general testing or linting skills. Not a 4 because the triggers (WCAG, accessibility, Spark UI) are distinct enough that wrong-skill activation is unlikely.	5 / 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: leboncoin/spark-web
Path: .cursor/skills/check-accessibility/SKILL.md
Commit: da35814

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