accessibility-testing

Accessibility testing with axe-core and Playwright. Use when checking WCAG compliance, finding a11y issues, ensuring keyboard navigation, or testing screen reader compatibility.

Quality

77%

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

Quality

Content

71%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.

The body is highly actionable: every section is executable, copy-paste-ready code spanning scans, WCAG levels, keyboard testing, forms, reporting, and CI. Its weaknesses are redundancy across near-identical examples and weak progressive disclosure — the two reference files exist but are barely wired into the body, while detail that belongs in them is inlined.

Suggestions

Collapse the three WCAG-level and three rule-category examples into one parameterized example plus a short table of tag sets, and remove the Basic Usage full-page scan that duplicates Quick Start.

Move detailed material (the HTML report generator, keyboard-navigation test patterns) into the existing references and link them inline from the relevant sections, e.g. 'For the full WCAG rule-to-test mapping see references/wcag-checklist.md'.

Reorder so Installation precedes Quick Start and add a brief explicit workflow note (install → add tests → run locally → wire into CI).

Dimension	Reasoning	Score
Conciseness	There is no conceptual padding, but the body is noticeably redundant: 'Basic Usage / Full Page Scan' nearly duplicates the Quick Start verbatim, and the three WCAG-level and three rule-category examples are structurally identical blocks that could collapse into one example plus a tag table. This is 'mostly efficient but could be tightened' rather than merely minor trimmings.	3 / 5
Actionability	All guidance is fully executable, copy-paste-ready code or commands (npm install, AxeBuilder scans with withTags/withRules/includes, keyboard-navigation tests, JSON/HTML reporting, GitHub Actions YAML) and the examples cover the common a11y testing cases end to end.	5 / 5
Workflow Clarity	The implicit install → write test → run → report → CI progression is discernible through well-ordered topical sections with working code, but there is no explicit sequence and Installation appears after Quick Start, leaving minor gaps rather than a fully explicit checkpointed workflow.	4 / 5
Progressive Disclosure	The two reference files (wcag-checklist.md, common-issues.md) exist, are one level deep, and are listed with one-line descriptions, but only as a bare footer list — never signaled from the sections they relate to — while ~400 lines of detail (three near-identical WCAG-level examples, the HTML report generator, keyboard patterns) are inlined in SKILL.md, matching 'references present but not clearly signaled; content that should be separate is inline'.	3 / 5
	Total	15 / 20 Passed

Description

73%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.

The description is well-constructed: it names concrete tools, uses third person, and includes an explicit 'Use when' clause with four natural, distinctive trigger phrases. Its main weakness is a thin what-statement that defers all specificity to the trigger clause.

Suggestions

Expand the what-statement into 2-3 concrete capabilities, e.g. 'Run axe-core scans in Playwright, check WCAG A/AA/AAA levels, and test keyboard navigation and forms.'

Add a few more natural trigger synonyms such as 'accessibility audit', 'color contrast', or 'ARIA issues' to broaden trigger coverage.

Dimension	Reasoning	Score
Specificity	Names the domain and concrete tools ("Accessibility testing with axe-core and Playwright") but the what-statement is a single action; the concrete activities (WCAG compliance, keyboard navigation, screen reader compatibility) appear only in the when-clause, matching 'names domain and 1-2 concrete actions, but not comprehensive' rather than the several-distinct-actions level.	3 / 5
Completeness	Both what ("Accessibility testing with axe-core and Playwright") and an explicit 'Use when' clause with four concrete triggers are present; it falls short of level 5 because the what is a single terse clause naming tools, unlike the multi-action capability statement in the level-5 anchor.	4 / 5
Trigger Term Quality	"checking WCAG compliance, finding a11y issues, ensuring keyboard navigation, or testing screen reader compatibility" are natural user phrases including the synonym 'a11y', but common variations like 'accessibility audit', 'contrast', or 'aria' are missing, so coverage is good rather than comprehensive.	4 / 5
Distinctiveness Conflict Risk	"WCAG compliance", "a11y issues", and "screen reader compatibility" are distinctive triggers for a clear niche (accessibility testing with named tools axe-core and Playwright), with minimal overlap risk against generic testing skills.	5 / 5
	Total	16 / 20 Passed

Validation

93%

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

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: fernandezbaptiste/Skrillz
Path: skills/accessibility-testing/SKILL.md
Commit: 93ed392

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