screen-reader-testing

Practical guide to testing web applications with screen readers for comprehensive accessibility validation.

Quality

27%

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/screen-reader-testing/SKILL.md

Quality

Content

18%Scale 1-5

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

This skill is essentially a hollow shell — it has a clear topic (screen reader testing) but provides no actionable content whatsoever. The instructions are generic boilerplate that could apply to any domain, and all substantive content is deferred to a referenced file that doesn't appear to exist in the bundle. A user or Claude following this skill would have no idea how to actually perform screen reader testing.

Suggestions

Add concrete, actionable testing steps: specific screen reader commands (e.g., NVDA: Insert+Down for read all, Tab for form navigation), keyboard shortcuts, and what to verify at each step.

Include at least one executable workflow, e.g., 'Testing a form: 1. Navigate to form with Tab, 2. Verify each label is announced, 3. Check error messages are announced on submit, 4. Verify focus management after submission.'

Add specific examples of common screen reader testing patterns: landmark navigation, heading structure verification, ARIA live region testing, and what correct vs incorrect announcements sound like.

Either provide the referenced `resources/implementation-playbook.md` bundle file or inline the essential content so the skill is usable standalone.

Dimension	Reasoning	Score
Conciseness	The content is relatively short but includes boilerplate sections ('Use this skill when' / 'Do not use this skill when') that add little value. The 'Do not use' section is particularly vacuous. The instructions section is generic filler rather than domain-specific guidance.	3 / 5
Actionability	The instructions are entirely vague and abstract — 'Clarify goals, constraints, and required inputs' and 'Apply relevant best practices' provide zero concrete guidance on how to actually test with screen readers. No commands, no code, no specific screen reader interactions, no keyboard shortcuts, no testing procedures.	1 / 5
Workflow Clarity	There is no meaningful workflow defined. The four bullet points in Instructions are generic platitudes that could apply to any skill. There are no sequenced steps, no validation checkpoints, and no specific testing procedures for screen reader testing.	1 / 5
Progressive Disclosure	The skill references `resources/implementation-playbook.md` for detailed patterns, which is a reasonable structure, but no bundle files were provided to verify the reference exists. The SKILL.md itself contains almost no substantive content — it delegates everything to a file that may not exist, making the skill useless on its own.	2 / 5
	Total	7 / 20 Passed

Description

36%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 identifies a clear domain (screen reader testing for web accessibility) but fails to list any concrete actions or capabilities, reads more like a document title than a skill description, and lacks any 'Use when...' trigger guidance. It would benefit significantly from specifying what actions the skill enables and when it should be selected.

Suggestions

Add a 'Use when...' clause with trigger terms like 'screen reader testing', 'accessibility audit', 'NVDA', 'VoiceOver', 'JAWS', 'ARIA roles', or 'a11y'.

Replace the vague 'practical guide' framing with concrete actions, e.g., 'Tests web applications with screen readers, validates ARIA attributes, checks keyboard navigation, and verifies focus management.'

Include specific screen reader names and standards (WCAG, Section 508) as trigger terms to improve distinctiveness and keyword coverage.

Dimension	Reasoning	Score
Specificity	Names the domain (testing web applications with screen readers) but provides no concrete actions. 'Practical guide' and 'comprehensive accessibility validation' are vague descriptors rather than specific capabilities.	2 / 5
Completeness	Has a vague 'what' (guide to testing with screen readers) but no 'when' clause at all. There is no explicit trigger guidance for when Claude should select this skill.	2 / 5
Trigger Term Quality	Includes relevant keywords like 'screen readers', 'accessibility', 'web applications', and 'testing', but misses common synonyms and natural phrases users might say such as 'a11y', 'NVDA', 'JAWS', 'VoiceOver', 'ARIA', 'WCAG', or 'assistive technology'.	3 / 5
Distinctiveness Conflict Risk	Somewhat specific to screen reader testing, which narrows it from general accessibility, but could still overlap with broader accessibility testing or web testing skills. The lack of specific actions or tools makes boundaries unclear.	3 / 5
	Total	10 / 20 Passed

Validation

90%

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 — 10 / 11 Passed

Validation for skill structure

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

	Total	10 / 11 Passed

Repository: administrakt0r/AI-Agents-Safe-Coding-Skills
Path: skills/screen-reader-testing/SKILL.md
Commit: 57c135b

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