Testing with Screen Readers
Use VoiceOver and NVDA to verify ARIA implementations.
Testing with Screen Readers is a free HTML Academy lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the HTML Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Test with Screen Readers?
Automated tools catch only 30-40% of accessibility issues. Real screen reader testing reveals problems automated checks miss:
- Confusing reading order
- Unhelpful ARIA announcements
- Missing focus management
- Confusing interactive patterns
VoiceOver on Mac
VoiceOver is built into macOS — no install needed:
<!-- Activate: Cmd+F5 (or System Settings → Accessibility → VoiceOver) -->
<!-- Key commands:
VO = Control+Option
VO+Right Arrow = Next element
VO+Left Arrow = Previous element
VO+Space = Activate element
VO+U = Open rotor (landmark navigation)
VO+H = Next heading
Tab = Next focusable element
Shift+Tab = Previous focusable
-->VoiceOver on iOS
Test mobile screen reader experience with VoiceOver on iPhone/iPad:
<!-- Activate: Settings → Accessibility → VoiceOver
Or: triple-click side button if set up -->
<!-- Gestures:
Swipe right = next element
Swipe left = previous element
Double-tap = activate element
Two-finger scrub = back
Three-finger swipe up/down = scroll
-->NVDA on Windows
NVDA is a free, open-source screen reader for Windows:
<!-- Download: nvaccess.org -->
<!-- Key commands:
NVDA key = Insert (or Caps Lock)
NVDA+N = NVDA menu
H = next heading
K = next link
B = next button
F = next form field
D = next landmark
Insert+F7 = element list (links, headings, landmarks)
-->Screen Reader Testing Checklist
What to verify with a screen reader:
- Page title is announced on load
- Headings create logical navigation structure
- All images have meaningful or empty alt text
- All form fields have labels
- Buttons and links have descriptive names
- Modal focus trap works correctly
- Dynamic content updates are announced
Common Screen Reader Bugs
Issues that automated tests miss:
<!-- 1. Reading order differs from visual order -->
<!-- CSS flex/grid order ≠ DOM order for screen readers -->
<!-- 2. aria-label doesn't match visible text -->
<!-- Voice control users say visible text to click -->
<!-- 3. Focus disappears after dialog closes -->
<!-- Programmatically return focus to trigger -->
<!-- 4. Dynamic content not in a live region -->
<!-- New items added silently, no announcement -->Keyboard-First Testing
Before using a screen reader, test keyboard-only first:
- Unplug your mouse or trackpad
- Navigate through the entire page with Tab only
- Verify every interactive element is reachable
- Verify all actions can be performed with keyboard
Automated Accessibility Testing Tools
Complement manual testing with automated tools:
- axe DevTools — Chrome extension; most accurate automated checker
- WAVE — wavebooth.com; visual overlay on the page
- Lighthouse — Chrome DevTools; Performance + Accessibility audit
- pa11y — CLI tool; great for CI/CD pipelines
ARIA Patterns Reference
The W3C ARIA Authoring Practices Guide (APG) provides reference implementations:
- Accordion, Alert, Alert Dialog
- Breadcrumb, Button, Carousel
- Checkbox, Combobox, Dialog
- Disclosure, Feed, Grid
- Listbox, Menu, Menubar
- Tab, Tooltip, Treeview
URL: w3.org/WAI/ARIA/apg/
Continuous Accessibility Integration
Build accessibility testing into your workflow:
// Jest + axe-core for unit tests:
import { axe, toHaveNoViolations } from 'jest-axe';
expect.extend(toHaveNoViolations);
test('Button is accessible', async () => {
const results = await axe('<button>Click me</button>');
expect(results).toHaveNoViolations();
});
// pa11y in CI pipeline:
// pa11y https://example.com --standard WCAG2AATesting Summary
A complete accessibility testing strategy:
- Design — check color contrast, touch target sizes
- Development — keyboard test, automated axe scan
- Review — screen reader test (VoiceOver + NVDA)
- CI/CD — pa11y or axe in automated pipeline
- Production — Lighthouse + manual spot checks
Quick Check
What percentage of accessibility issues can automated tools reliably catch?
Recap: Screen Reader Testing
Testing essentials:
- VoiceOver (Mac/iOS) and NVDA (Windows) are free and essential
- Test keyboard-only first; then add screen reader
- Automated tools: axe, WAVE, Lighthouse, pa11y
- Automated tests catch only ~30-40% of issues
- Reference APG patterns for correct ARIA implementations
Frequently asked questions
Is the “Testing with Screen Readers” lesson free?
Yes — the full text of “Testing with Screen Readers” is free to read here on the web, and the HTML Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the HTML Academy course, upgrade to CoddyKit PRO.
What will I learn in “Testing with Screen Readers”?
Use VoiceOver and NVDA to verify ARIA implementations. You practise HTML Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start HTML Academy?
No prior experience is required. HTML Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Testing with Screen Readers” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this HTML Academy lesson?
Yes. Every HTML Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.