screen-reader-testing

Use when performing accessibility audits of web pages, components, or full user flows. Applies to all web content accessed via assistive technology. Particularly important for custom JavaScript widgets, single-page applications, dynamically updated content, modal dialogs, and forms with validation.

Quality

67%

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

65%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-structured, actionable overview with excellent progressive disclosure: specific screen reader/browser combos, exact navigation keys, concrete fixes, and a clean one-level pointer to references/rule.md. Its weaknesses are the 'Explain' section teaching concepts Claude already knows, redundancy between Quick Reference and Check, and the absence of an explicit re-test/validation loop after fixes.

Suggestions

Cut or relocate the 'Explain' section's background (what screen readers are, what the accessibility tree is) into references/rule.md — Claude already knows this, and rule.md already covers 'Why It Matters'.

Remove the duplication between 'Quick Reference' and 'Check' (browser combos, live regions/modals/widgets appear in both); keep one.

Add an explicit validation step to the workflow: after each fix, re-run the screen reader check that caught the issue and confirm the announcement/keyboard behavior before moving on.

Dimension	Reasoning	Score
Conciseness	The 'Explain' section restates concepts Claude already knows ('Screen readers convert web content to audio or braille output... the accessibility tree — a parallel representation of the DOM'), and the 'Quick Reference' bullets duplicate content from 'Check' (browser combos, live regions, modals, widgets). The body is mostly efficient but the over-explanation exceeds anchor 4's 'minor instances' bar.	3 / 5
Actionability	Concrete and executable throughout: named tool combos ('NVDA + Chrome or Firefox on Windows; JAWS + Chrome... VoiceOver + Safari'), exact navigation keys ('Tab... H key... D/R keys... Insert+F7'), and specific fixes ('return focus to the trigger element', "aria-live='polite'", 'roving tabindex for menus'). Minor gaps — no worked test transcript or markup example — keep it below anchor 5.	4 / 5
Workflow Clarity	The Check → Fix structure gives a usable sequence with a concrete verification list ('reachable and announced with name + role + state'), but there are no explicit checkpoints or a re-test loop after applying fixes, so validation remains implicit. Anchor 4 requires most checkpoints to be present.	3 / 5
Progressive Disclosure	The body stays overview-level with well-organized sections (Quick Reference / Check / Fix / Explain / Code Review) and a single clearly signaled, one-level-deep reference — 'For full implementation details, code examples, and framework-specific guidance, see references/rule.md' — which exists as a real 85-line file. This matches anchor 5 exactly.	5 / 5
	Total	15 / 20 Passed

Description

70%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 has an excellent, detailed trigger clause and rich context keywords, but never mentions 'screen reader' — the term users would most naturally say — and states only one generic capability verb ('performing accessibility audits') without saying what the skill actually does. It reads mostly as a 'when' with a weak 'what'.

Suggestions

State the core capability explicitly, e.g., 'Test web pages with screen readers (NVDA, JAWS, VoiceOver, TalkBack): verify keyboard reachability, announcements (name/role/state), live regions, and modal focus behavior.'

Add the missing natural trigger terms: 'screen reader', 'screen reader testing', 'a11y', and 'WCAG' — users searching for this skill will say 'screen reader', not 'assistive technology'.

Tighten the trigger contexts to the highest-signal ones (custom widgets, SPAs, modals, validation forms) to reduce overlap with general accessibility-audit skills.

Dimension	Reasoning	Score
Specificity	The only action stated is 'performing accessibility audits of web pages, components, or full user flows' — domain plus one generic action — though concrete scope contexts ('custom JavaScript widgets, single-page applications, dynamically updated content, modal dialogs, and forms with validation') lift it above anchor 2. It falls short of anchor 4, which requires several specific actions.	3 / 5
Completeness	An explicit 'Use when...' clause is present and unusually detailed ('Applies to all web content accessed via assistive technology. Particularly important for...'), so the completeness-3 cap does not apply. However the 'what' is thin — 'performing accessibility audits' never says what the skill actually does (e.g., test with NVDA/VoiceOver, verify announcements, check keyboard operability) — keeping it below anchor 5.	4 / 5
Trigger Term Quality	Good natural keyword coverage ('accessibility audits', 'web pages', 'components', 'user flows', 'assistive technology', 'modal dialogs', 'forms with validation') but it misses the most natural trigger term — 'screen reader' — along with 'a11y', 'WCAG', and specific tool names, so it does not reach anchor 5's synonym/extension-level coverage.	4 / 5
Distinctiveness Conflict Risk	'accessibility audits... accessed via assistive technology' carves a recognizable niche with concrete trigger contexts, but it overlaps with adjacent accessibility skills (general a11y audits, WCAG checks, keyboard testing) and never states its actual differentiator — screen reader testing specifically — so it stops short of anchor 5's minimal-conflict bar.	4 / 5
	Total	15 / 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
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/screen-reader-testing/SKILL.md
Commit: 7bfd868

Reviewed: 1 day 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.