What Screen Readers Reap When Eyes Can't See

Two versions of every page

Every web page has a visual presentation and a structural one. Sighted users see colors, layouts, whitespace, and imagery. Screen reader users hear a linearized sequence of text, announced with roles, states, and names derived from the underlying HTML.

These two experiences can diverge dramatically. A page that looks polished and intuitive can sound like a jumbled mess when read aloud. And a page that looks simple can be beautifully navigable through a screen reader, if the markup is right.

What gets announced

Screen readers process the DOM (the Document Object Model), not the pixels. They announce elements based on their semantic role and content:

• Headings are announced with their level: "Heading level 2, Our Services." Users navigate by headings constantly; it's their primary way to scan a page.
• Links are announced with their text: "Link, Contact Us." If the link text is "Click here," that's all the user hears. Out of context, meaningless.
• Images are announced with their alt text, or their filename if alt text is missing.
• Lists are announced with their item count: "List, 5 items." This gives users a sense of scope before they start navigating the items.
• Form inputs are announced with their label and type: "Email address, edit text." No label? The user hears "edit text" and guesses.

What gets ignored

CSS is invisible to screen readers. That means:

• Visual order created by Flexbox or Grid order properties doesn't change the reading order. The DOM order is what gets read.
• Content hidden with display: none or visibility: hidden is properly excluded. Content positioned off-screen with CSS is still announced, which is useful for skip links and screen-reader-only text.
• Decorative elements should be hidden with aria-hidden="true" or empty alt="" to prevent screen readers from announcing meaningless content.

Common pain points

Icon buttons with no labels

A hamburger menu icon with no accessible name announces as "button": just "button." The user has no idea what it does. Every icon-only control needs an aria-label or visually hidden text to provide meaning.

Modals that don't trap focus

When a modal opens, focus should move into it, and Tab should cycle within it until the modal is closed. Without focus trapping, users tab behind the modal into content they can't see, interacting with a page they're supposed to be blocked from.

Dynamic content with no announcements

Content that updates without a page reload (toast notifications, live search results, chat messages) needs ARIA live regions to be announced. If the DOM changes and the screen reader doesn't know, the user misses the update entirely.

Listen to your own site

The single most valuable accessibility exercise any developer can do: turn on a screen reader and navigate your site. VoiceOver is built into every Mac. NVDA is free on Windows. TalkBack is built into Android.

You don't need to become an expert user. You need to hear what your markup actually produces: the gaps, the confusion, the moments where the audio version diverges from the visual one. eiSEO will catch the structural issues. But the screen reader test reveals the experience, and that's what determines whether your site is genuinely usable or just technically compliant.

The harvest your screen reader users reap depends entirely on the seeds you plant in your HTML. Make sure what grows is worth gathering.