What can screen readers not read
Screen readers are pretty amazing, honestly. They take digital text and turn it into speech or braille, which lets people with visual impairments actually use websites, documents, apps. But they're not magic. There's stuff they just can't handle. If you're trying to make content that's actually accessible, you've gotta know where the gaps are. That's what we're digging into here—the real barriers and what you can do about them.
Images and Non-Text Content Without Proper Descriptions
The biggest headache for screen readers? Visual stuff with no text backup. If an image doesn't have an alt attribute—or worse, it's there but empty—the reader either skips it entirely or reads the file name. "IMG_4572.jpg." Super helpful, right? This covers everything: photos, diagrams, icons, charts. All of it.
- Missing alt text: The reader just can't figure out what the image is about. It's blind to it.
- Complex graphics: Infographics, data visualizations—forget it unless there's a proper text description somewhere.
- Decorative images: These should have
alt=""so the reader ignores them. But if that's missing? Confusion city.
WebAIM's Million report found that over half of home page images don't have alternative text. So those images basically don't exist for screen reader users.
Unstructured or Complex Tables
Tables are doable for screen readers, but only if the structure's clear. When markup's sloppy, the reader can't connect data cells to their headers. You end up with a mess of numbers and words that makes zero sense.
| Issue | What Screen Reader Does | Solution |
|---|---|---|
| No header cells | Reads everything straight through, context gone | Use <th> with scope |
| Merged cells | Might skip or mess up the merged parts | Use colspan and rowspan properly |
| Layout tables | Tries to read it like data—total confusion | Don't use tables for layout. CSS exists. |
Interactive Elements Without Proper Labels
Forms, buttons, links—these trip up screen readers all the time. If a form field has no visible or programmatic label, the user just hears "edit text" with zero clue what to type. And buttons with only an icon, like a magnifying glass for search? Silent unless there's an accessible namep>
- Unlabeled form fields: User gets "edit text." That's it. No context at all.
- Icon-only buttons: Reader skips 'em or just says "button." Useless.
- Dynamic content: Stuff that changes via JavaScript, like error messages—often doesn't get announced without ARIA live regions.
People Also Ask: Can screen readers read PDFs?
Yeah, but only tagged ones. Untagged PDFs are basically images of text. The reader tries to plow through linearly, but reading order gets jumbled, columns get skipped, headings vanish. You need proper tags, a clear reading order, and alt text for images to make PDFs work.
People Also Ask: What about videos and audio?
Screen readers can't see what's happening in videos. They can read the play/pause buttons, sure, but the actual video content? Invisible. That's why captions and audio descriptions matter so much. Audio descriptions narrate the visual action, captions handle spoken words. Without 'em, users miss critical stuff.
People Also Ask: Can screen readers read CAPTCHAs?
Oh, CAPTCHAs. The bane of accessibility. Traditional visual ones? Forget it. The reader can't solve distorted text or pick out objects in images. Audio CAPTCHAs exist, but they're often just as hard to understand. Better options: logic puzzles, honeypot fields, or biometric stuff.
People Also Ask: Do screen readers handle emojis and special characters?
They do read emojis, but it's not pretty. The reader announces the Unicode description—"grinning face with sweat"—which gets annoying fast if you overdo it. Special characters like arrows or math symbols get read as "less than" or "greater than," which can confuse people. Use 'em sparingly and always provide text alternatives when possible.
Checklist for Accessible Content
- Give all meaningful images decent alt text.
- Use proper heading hierarchy—h1 through h6—for structure.
- Label every form field with clear instructionsli>
- Make sure tables have header cells and captions.
- Add captions and audio descriptions to videos.
- Test with a real screen reader—NVDA, JAWS, VoiceOver, whatever.
Frequently Asked Questions
Can screen readers read JavaScript?
They can read what JavaScript generates, but dynamic updates often slip through. Use ARIA live regions to announce changes like loading states or errors.
What is the biggest mistake developers make?
Relying only on visual cues. If someone can't see, you need text alternatives for everything—images, interactive elements, all of it.
Are all screen readers the same?
Not even close. NVDA's free and open source, JAWS costs money but is widely used, VoiceOver comes built into Apple stuff. They all handle HTML and ARIA a little differently.
How can I test my site?
Use tools like WAVE or Axe, then manually test with a screen reader. Here's a challenge: turn off your monitor and try navigating with just the keyboard and reader. It's eye-opening.
Short Summary
Short Summary
- Images without alt text: Screen readers can't interpret visual content, making alt text essential for accessibility.
- Unstructured tables: Without proper headers and scope, data tables become a confusing list of numbers.
- Unlabeled interactive elements: Forms, buttons, and dynamic content need clear labels or ARIA attributes to be usable.
- Multimedia and CAPTCHAs: Videos need captions and audio descriptions; visual CAPTCHAs block access entirely.