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

76%

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

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 with concrete commands, executable code, and clear test scripts, and it is well-organized by section. Its main weaknesses are token inefficiency from inlining ~540 lines of reference material and the absence of progressive disclosure via separate reference files.

Suggestions

Move the per-screen-reader command references, testing checklists, and full scenario code (modal/tab/live-region JS) into reference files under ./references/ and link to them one level deep, leaving SKILL.md as a concise overview.

Trim or remove full JavaScript implementations (focus-trap, tab keyboard handling) that Claude can already generate, keeping only the accessibility-specific assertions and ARIA patterns that matter.

Add an explicit feedback loop to the test scripts (e.g., "If a check fails: note the issue, apply the matching fix from Common Issues, then re-verify") to convert checklists into true validation checkpoints.

Dimension	Reasoning	Score
Conciseness	The ~540-line body is dense and mostly free of padded fluff, but it inlines large reference blocks (full command tables, complete checklists, and full JS focus-trap/modal implementations Claude could already write) that could be tightened or moved out, fitting anchor 3 rather than the lean anchor 5.	3 / 5
Actionability	Provides copy-paste-ready commands (VO + Right Arrow, NVDA + Down Arrow, H for headings), executable HTML/JS examples for modals, live regions, and tabs, plus concrete test scripts and checklists covering the common cases, matching anchor 5.	5 / 5
Workflow Clarity	The NVDA Test Script gives a clear sequenced workflow (Initial Load → Landmarks → Headings → Forms → Interactive → Dynamic Content) with check items, but it lacks explicit validate→fix→retry feedback loops tying failed checks to corrective action, so it sits at anchor 4 rather than 5.	4 / 5
Progressive Disclosure	The file is well-structured with clear section headers, but command references, checklists, and scenario code that clearly belong in separate reference files are all inlined in SKILL.md with no one-level-deep file references (no bundle files exist), matching anchor 3.	3 / 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.

The description is strong: it clearly states what the skill does and when to use it with concrete, natural trigger terms and a distinct niche. Its only weakness is that the "what" relies on a single action verb (test) rather than enumerating several concrete testing actions.

Suggestions

Expand the "what" clause with a few concrete actions (e.g., "navigate via rotor, verify ARIA announcements, check focus management") to lift specificity from a single verb to multiple distinct actions.

Consider adding widely-used natural terms like "ARIA", "WCAG", or "TalkBack" to round out trigger term coverage.

Dimension	Reasoning	Score
Specificity	"Test web applications with screen readers including VoiceOver, NVDA, and JAWS" names the domain and concrete tools but only offers a single action verb (test); the named tools add specificity but not additional actions, matching anchor 3 rather than the multi-action anchor 5.	3 / 5
Completeness	Explicitly answers both 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 anchor 5.	5 / 5
Trigger Term Quality	Includes natural terms a user would say — "screen readers", "VoiceOver, NVDA, JAWS", "screen reader compatibility", "accessibility issues", "assistive technology support" — giving good coverage, though common variants like ARIA, WCAG, or TalkBack are absent, keeping it below anchor 5.	4 / 5
Distinctiveness Conflict Risk	Occupies a clear niche (screen reader accessibility testing) with named tools and distinct triggers, creating minimal overlap risk with other skills, matching anchor 5.	5 / 5
	Total	17 / 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: 6453c0b

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