WCAG 2.1 Levels Explained: A-AA-AAA
What’s the difference between A, AA, and AAA compliance? We break down each level…
Read ArticleScreen Readers and Assistive Technology
Learn how people with visual impairments navigate the web. We’ve got practical tips for testing your site with common screen readers.
Why Screen Readers Matter
Over 2.2 billion people globally experience some form of vision loss. That’s roughly one in every four people over 50. For many of them, screen readers aren’t a luxury — they’re the gateway to accessing information online.
A screen reader is software that reads web content aloud. It converts text, links, and interface elements into speech or Braille output. The most common ones? NVDA (free), JAWS (Windows), VoiceOver (Mac/iOS), and TalkBack (Android). They’re not magic, though. They rely entirely on how well you’ve structured your HTML and labeled your elements.
The Foundation: Semantic HTML
Here’s what most developers get wrong: they don’t realize screen readers navigate using HTML structure. Use actual heading tags (h1, h2, h3) instead of divs styled to look like headings. Use lists for lists. Use buttons for buttons, not divs with click handlers.
When you write proper semantic HTML, screen readers create a navigation outline automatically. A user can jump between headings, skip to main content, or navigate by landmark regions. You don’t even need to add extra code — you’re already halfway there.
Quick reality check: If your site only works with a mouse, you’ve already broken it for screen reader users. Keyboard navigation and screen reader compatibility go hand in hand.
Testing with Real Screen Readers
You don’t need to be blind to test your site with a screen reader. Everyone should spend 15 minutes with one. You’ll discover problems you didn’t know existed.
NVDA (Windows/Linux)
Free, open-source
Start here if you’re new. NVDA is completely free and works well for testing. Download it, turn it on, and navigate your site using Tab and arrow keys. You’ll immediately hear where your labels are missing.
VoiceOver (Mac/iOS)
Built-in, no installation
Already on your Mac. Press Command+F5 to enable it. VoiceOver is powerful and widely used. Testing on Mac gives you insight into how real users experience your site on Apple devices.
JAWS (Windows)
Industry standard, paid
The most popular professional screen reader. It’s expensive but has a 40-minute trial mode. If you’re building something important, testing with JAWS shows you’re serious about accessibility.
Six Techniques That Actually Work
01
Write Descriptive Link Text
Don’t use “click here” or “read more.” Screen reader users often navigate by links alone. Make each link meaningful. “Learn about WCAG 2.1 requirements” tells you what you’re getting. “Click here” doesn’t.
02
Alt Text That Describes, Not Labels
Alt text should convey the meaning and purpose, not just say “image” or “photo.” For a chart showing accessibility statistics, your alt should describe the data. For decorative images, leave alt empty.
03
Use ARIA Labels Strategically
ARIA (Accessible Rich Internet Applications) isn’t a replacement for semantic HTML — it’s a supplement. Use aria-label for icon buttons, aria-describedby for complex components, and aria-live for dynamic content that updates without page reload.
Beyond the Basics: Advanced Considerations
Screen reader users aren’t a monolith. Some users have partial vision and use magnification software alongside a screen reader. Others use voice control instead of keyboard navigation. Some switch between multiple assistive technologies depending on their task.
This means testing with just one screen reader isn’t enough. You’ve got to consider the whole ecosystem. Does your site work with keyboard-only navigation? Can users resize text? Is there enough color contrast that magnified text is still readable? Does your dynamic content announce changes properly?
“The best accessibility features are invisible. They don’t require learning. They just work the way users expect.”
— Web Accessibility Principle
Practical Testing Checklist
Navigation Structure
Can you navigate the entire site using only Tab and Enter keys? Does the focus indicator move in logical order?
Heading Hierarchy
Does your page start with h1? Do headings skip levels (like h1 to h3)? Screen readers depend on proper hierarchy.
Form Labels
Every form input must have a label associated with it. Placeholder text alone isn’t enough — screen readers need the label element.
Images and Alt Text
Do all images have meaningful alt text? Are decorative images marked with empty alt attributes?
Dynamic Content
When content updates without page reload, does the screen reader announce the change? Use aria-live regions for this.
Color Contrast
Don’t rely on color alone to convey information. Ensure at least 4.5:1 contrast ratio for normal text.
Making It Real
Building for screen readers isn’t complicated. It’s mostly about understanding how these tools work and respecting the structure they depend on. Start with semantic HTML. Test with a free screen reader. Listen to what users hear. That’s genuinely enough to catch most problems.
The goal isn’t perfection. It’s making sure your site works for everyone, including people you’ve never met and probably won’t meet. Screen readers are the bridge that makes that possible.
Important Note
This guide provides educational information about screen readers and assistive technology accessibility practices. It’s not exhaustive, and accessibility requirements vary by jurisdiction and industry standards. WCAG guidelines evolve, and your specific situation may require additional considerations. For compliance in Canada, consult current Canadian accessibility standards and consider professional accessibility auditing. Testing with real users who rely on assistive technology is invaluable — automated tools can’t catch everything.
Related Articles
