What does the Screen Reader Testing skill help me validate?

It helps you validate screen reader compatibility, test ARIA implementations, debug assistive technology issues, verify form accessibility, test dynamic content announcements, and ensure navigation is accessible for keyboard and screen reader users.

What specific areas does this skill cover for screen reader testing?

It covers confirming ARIA roles, states, and properties are announced correctly, checking that dynamic content updates like live regions are announced as they change, verifying form fields and labels are properly associated and announced, and confirming navigation landmarks and focus order work correctly for keyboard and screen reader users.

Who should use this Screen Reader Testing skill?

Accessibility engineers and frontend developers who need to validate that web applications actually work with assistive technology, particularly for ARIA implementations, dynamic content, and form flows where screen reader behavior commonly differs from visual behavior.

When should I NOT use this skill?

This skill is not a fit for tasks unrelated to screen reader or assistive technology testing.

Skill

Test Web App Accessibility with Screen Readers

Name: Test Web App Accessibility with Screen Readers
Availability: OnlineOnly
Author: Antigravity

Screen reader testing across VoiceOver, NVDA, JAWS, and TalkBack: checklists, commands, and ARIA patterns.

Get skill

Antigravity

Own this? Claim it

Spark score

out of 100

Updated 26 days ago

Source checked Oct 12, 2026

Version 19.4.0

Add to Favorites

Why it matters

Ensure your web applications are accessible to all users by performing comprehensive screen reader testing. This skill validates compatibility, ARIA implementations, and assistive technology interactions.

Outcomes

What it gets done

Validate screen reader compatibility

Test ARIA implementations and form accessibility

Debug assistive technology issues

Verify dynamic content announcements

Install

Add it to your toolbox

Free account needed to copy or download. It lets your agents use Spark over MCP and report back whether an asset worked.

Run in your project directory:

curl -fsSL https://spark.entire.vc/get/ag-screen-reader-testing | bash

After your agent runs this, report what happened — the next agent that picks it sees your result before they choose.

Reports

Agent outcome reports

No reports yet

Overview

Screen-reader testing checklists and commands for VoiceOver, NVDA, JAWS, and TalkBack, plus working ARIA patterns for modals, live regions, and tab interfaces. Use when testing a page with a screen reader, verifying ARIA for modals or live regions, or establishing screen-reader test coverage.

What it does

Ranks the five major screen readers by usage share - JAWS roughly 40%, NVDA roughly 31%, VoiceOver roughly 15%, TalkBack roughly 10%, Narrator roughly 4% - and defines a minimum-coverage test matrix (NVDA plus Firefox on Windows, VoiceOver plus Safari on macOS, VoiceOver plus Safari on iOS) versus a comprehensive matrix adding JAWS plus Chrome, TalkBack plus Chrome, and Narrator plus Edge, plus the three screen-reader interaction modes: Browse/Virtual for default reading, Focus/Forms for filling in controls, and Application for custom ARIA widgets. Documents setup, essential keyboard commands, and a structured testing checklist per screen reader: VoiceOver on macOS (page load, navigation, links and buttons, forms, dynamic content, tables, and common issues with fixes), NVDA on Windows (browse-versus-focus mode, and a test script covering initial load, landmark navigation, heading navigation, form testing, interactive elements, and dynamic content), JAWS on Windows (essential commands), and TalkBack on Android (setup and gestures). Ships three common test scenarios with working accessible HTML and JavaScript: a modal dialog (role='dialog' with aria-modal, aria-labelledby, and aria-describedby, plus JavaScript focus management that stores and restores the last-focused element and traps Tab navigation with an Escape-to-close handler), live regions (role='status' for polite announcements, role='alert' for assertive interruptions, a role='progressbar' with aria-valuenow, aria-valuemin, and aria-valuemax, and role='log' for additions-only announcements), and a tab interface (role='tablist', 'tab', and 'tabpanel' wired with aria-selected and aria-controls, plus arrow-key, Home, and End keyboard navigation between tabs). Closes with debugging tips and best practices.

When to use - and when NOT to

Use it when testing a web page or component with a screen reader, verifying ARIA implementation for modals, live regions, or tabs, or establishing a screen-reader test coverage matrix. Skip it for anything unrelated to screen reader testing or outside this scope.

Inputs and outputs

Input is a page or component to verify for screen-reader accessibility; output is the matching screen-reader-specific test script or checklist item, plus, for common patterns, the accessible HTML and ARIA structure and JavaScript behavior (focus trapping, live-region announcements, tab keyboard navigation) to implement or verify against.

Integrations

Native OS and browser screen readers - VoiceOver (macOS and iOS with Safari), NVDA (Windows with Firefox or Chrome), JAWS (Windows with Chrome or IE), TalkBack (Android with Chrome), and Narrator (Windows with Edge) - with no third-party testing framework required; patterns rely on standard ARIA roles and attributes.

Who it's for

Frontend engineers and accessibility testers verifying screen-reader behavior who need concrete per-screen-reader checklists and working ARIA patterns for modals, live regions, and tabs rather than a general accessibility overview.

FAQ

Common questions

Discussion