screen-reader-testing

Test web applications with screen readers including VoiceOver, NVDA, and JAWS. Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support.

1.07x

Quality

68%

Does it follow best practices?

Impact

100%

1.07x

Average score across 3 eval scenarios

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./tests/ext_conformance/artifacts/agents-wshobson/accessibility-compliance/skills/screen-reader-testing/SKILL.md

The canonical home for this skill is screen-reader-testing in wshobson/agents

Quality

Content

57%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 a genuinely useful, highly concrete reference with exact commands and checklists per screen reader, but it is a monolithic single file that inlines content Claude already knows (standard ARIA widget patterns) alongside the reference material it genuinely needs. Splitting per-reader command sheets into references/ files and adding an end-to-end testing workflow would materially improve it.

Suggestions

Move the per-reader command sheets (VoiceOver, NVDA, JAWS, TalkBack) into references/ files (e.g. references/voiceover.md) and keep SKILL.md as an overview with the testing-priority matrix and links, per the one-level-deep pattern.

Cut or compress the modal focus-trap, tablist, and live-region code examples to short ARIA markup reminders — these are WAI-ARIA APG patterns Claude already knows — and keep only the screen-reader-specific verification steps.

Add a top-level end-to-end workflow (choose readers by priority → set up → run the test script → fix issues using Common Issues & Fixes → retest the failed items) so the checklists and fixes are sequenced rather than presented side-by-side.

Dimension	Reasoning	Score
Conciseness	The command tables, checklists, and test scripts are dense and earn their tokens, but roughly 150 lines (modal focus-trap JS, tablist keyboard navigation, live-region patterns) restate standard WAI-ARIA Authoring Practices patterns Claude already knows well and could be trimmed or cut.	3 / 5
Actionability	Highly concrete throughout — exact keystrokes, setup toggles, numbered test scripts with embedded checks, and copy-ready ARIA fixes — but some JavaScript relies on implicit globals (lastFocus, tablist, activateTab), leaving minor gaps versus fully executable.	4 / 5
Workflow Clarity	Per-reader sequences (setup → commands → checklist) and the NVDA test script with embedded "Check:" steps exist, but the skill never assembles them into one end-to-end workflow (pick readers by priority → run script → triage failures via Common Issues & Fixes → retest), and there is no fix-and-retest feedback loop.	3 / 5
Progressive Disclosure	The single 546-line file is well-sectioned with clear headers, but the per-reader command references (VoiceOver ~90 lines, NVDA ~120 lines, JAWS, TalkBack) and scenario code are exactly the on-demand material that belongs in one-level-deep references/ files, and no internal references exist.	3 / 5
	Total	13 / 20 Passed

Description

78%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 that clearly states what the skill does and when to use it, with concrete tool names serving as natural triggers. Its main weaknesses are a single generic capability verb ("Test") and missing common accessibility synonyms like "a11y" or "accessibility audit".

Suggestions

Enumerate concrete capabilities instead of the single verb "Test", e.g. "Test web applications with screen readers (VoiceOver, NVDA, JAWS, TalkBack): run structured test scripts, audit forms and dynamic announcements, diagnose misannounced elements".

Add common trigger synonyms such as "a11y", "accessibility testing", or "WCAG conformance checks" to broaden natural-term coverage.

Narrow the "debugging accessibility issues" trigger toward screen-reader-specific phrasing to reduce overlap with general web-accessibility skills.

Dimension	Reasoning	Score
Specificity	Names the domain and the three dominant tools ("screen readers including VoiceOver, NVDA, and JAWS") but offers only one capability verb ("Test web applications"), matching the anchor for domain plus 1-2 concrete actions rather than the several distinct actions needed for a 4.	3 / 5
Completeness	Explicitly answers both parts: what ("Test web applications with screen readers including VoiceOver, NVDA, and JAWS") and when ("Use when validating screen reader compatibility, debugging accessibility issues, or ensuring assistive technology support") with concrete trigger phrases, matching the top anchor exactly.	5 / 5
Trigger Term Quality	Good natural keyword coverage — "VoiceOver", "NVDA", "JAWS", "screen reader compatibility", "accessibility issues", "assistive technology" — but common variations like "a11y", "WCAG", or "accessibility audit" are absent, so it falls short of comprehensive synonym coverage.	4 / 5
Distinctiveness Conflict Risk	The named screen readers give it a clear niche with distinct triggers, but the broad phrase "debugging accessibility issues" could also fire a general web-accessibility or WCAG-audit skill, leaving minor overlap risk with closely related skills.	4 / 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
skill_md_line_count	SKILL.md is long (546 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: Dicklesworthstone/pi_agent_rust
Path: tests/ext_conformance/artifacts/agents-wshobson/accessibility-compliance/skills/screen-reader-testing/SKILL.md
Commit: a65ce00

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