CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

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.

Quality

62%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/screen-reader-testing/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

22%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 well-sectioned and brief but hollow: its Instructions are generic boilerplate that could apply to any skill, and all substance is deferred to a `resources/implementation-playbook.md` that is missing from the bundle. There is no concrete guidance on how to actually launch, drive, or verify results with VoiceOver, NVDA, or JAWS.

Suggestions

Replace the generic Instructions bullets with concrete, tool-specific guidance: how to start and control each screen reader (e.g., VoiceOver with Cmd+F5, NVDA's browse/focus modes, JAWS virtual cursor) and which announcements to listen for on common widgets.

Add a sequenced workflow with validation checkpoints, e.g.: define test scope -> walk each component with the screen reader -> record the exact announcement heard vs. expected -> fix -> re-test. The re-test loop closes the feedback cycle the rubric expects.

Fix the dangling reference: `resources/implementation-playbook.md` is cited twice but does not exist in the bundle — either ship the playbook or inline its key patterns into SKILL.md.

DimensionReasoningScore

Conciseness

The body is short with no concept re-teaching, but it is padded with generic filler: "Clarify goals, constraints, and required inputs. Apply relevant best practices and validate outcomes." and the tautological "Do not use this skill when — The task is unrelated to screen reader testing" bullets could apply to any skill and add nothing screen-reader-specific. This fits 'mostly efficient but includes some unnecessary explanation or could be tightened' better than anchor 4's 'minor instances', since the boilerplate constitutes the core Instructions section.

3 / 5

Actionability

The Instructions are entirely abstract — "Apply relevant best practices and validate outcomes" and "Provide actionable steps and verification" — with no concrete commands, screen-reader keyboard shortcuts, tool launch steps, or examples anywhere in the body. This matches the lowest anchor ('entirely vague or abstract; no concrete code or commands; only describes rather than instructs'); anchor 2 would require at least a high-level task hint, which is absent. The only concrete pointer, `resources/implementation-playbook.md`, targets a file that does not exist in the bundle.

1 / 5

Workflow Clarity

No testing sequence is present: there are no ordered steps for launching a screen reader, navigating the application, checking announcements, or verifying fixes, and no validation checkpoints — 'steps missing or incoherent; no sequence'. Anchor 2 requires a rough sequence, which the body does not provide. The under-50-lines simple-skill exception does not apply because the body lists multiple sub-tasks (ARIA, forms, dynamic content, navigation) yet gives no unambiguous single action for any of them.

1 / 5

Progressive Disclosure

Sections are well-organized (Use when / Do not use / Instructions / Resources) and the reference to `resources/implementation-playbook.md` is clearly signaled in both Instructions and Resources, which is better than anchor 3's 'references present but not clearly signaled'. However, that file does not exist — the bundle contains no resources/ directory — so the promised detail layer is empty and the content split is broken. This disqualifies anchor 4 ('most content is appropriately placed; minor organization gaps') because the missing playbook is not a minor gap; it is the entire substance of the skill.

3 / 5

Total

8

/

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.

A strong description that clearly states both what the skill does and when to use it, with specific screen reader names and natural trigger phrases. Its only weakness is thin action variety — a single 'Test' verb rather than several concrete capabilities — which is why specificity sits at the mid anchor.

DimensionReasoningScore

Specificity

"Test web applications with screen readers including VoiceOver, NVDA, and JAWS" names the domain and concrete tools, but lists only a single action ('Test') — fitting 'Names domain and 1-2 concrete actions, but not comprehensive'. It does not reach anchor 4, which requires several specific actions (e.g., navigate, capture announcements, inspect ARIA output); the verbs in the 'when' clause (validating, debugging, ensuring) are usage triggers, not capability actions.

3 / 5

Completeness

It 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 three concrete trigger phrases, exactly matching the top anchor's what+when-with-concrete-triggers pattern. Anchor 4 ('when could be more explicit or specific') does not apply since the when-clause is explicit and enumerates distinct scenarios.

5 / 5

Trigger Term Quality

Good natural-keyword coverage: "screen reader compatibility", "accessibility issues", "assistive technology support", plus the specific tool names "VoiceOver, NVDA, and JAWS" — all phrases a user would naturally say. It falls short of anchor 5's comprehensive coverage because common variations like "a11y", "WCAG", "accessibility audit", or "screen reader testing" as a noun phrase are missing.

4 / 5

Distinctiveness Conflict Risk

The named screen readers ("VoiceOver, NVDA, and JAWS") and "assistive technology support" carve out a clear niche with distinct triggers, matching 'clear niche with distinct triggers; minimal conflict risk'. The tool names alone would disambiguate this from generic accessibility or frontend-testing skills, so anchor 4's 'minor overlap risk' understates it.

5 / 5

Total

17

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

rmyndharis/antigravity-skills

Path

skills/screen-reader-testing/SKILL.md

Reviewed

Table of Contents

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.