Website Accessibility for Visually Impaired Users: The Screen Reader Test

Most site owners find out their site is broken for blind users the same way — a customer sends an email saying they could not check out, or a demand letter lands in the mail. Neither moment is the right one to learn that website accessibility for visually impaired users was never actually tested. The audit tool said 94%. The screen reader tells a different story.

Automated scanners catch roughly 30 to 40 percent of real accessibility failures, according to published research from Deque and WebAIM's annual WebAIM Million report. The rest only appear when a person actually navigates with a screen reader like NVDA, JAWS, or VoiceOver. This guide walks through what happens during that test, the seven silent failures that keep blocking visually impaired users in 2026, and the order you should fix them in.

What a Screen Reader Actually Does On Your Site

A screen reader reads a page top to bottom as a linear document, announcing elements by their semantic role. It does not see layout. It does not see color. It does not see the beautiful hero section your designer built. It announces what the HTML tells it to announce, in the order the HTML presents it.

That single fact explains most failures. A button styled to look like a button but built as a div is invisible to the assistive technology. A modal that visually covers the page but does not trap keyboard focus sends the user reading content behind it. An icon that shows a magnifying glass to a sighted user announces as nothing at all — the user hears silence where the search button should be.

Try this yourself. On a Mac, press Command-F5 to turn on VoiceOver. Use Control-Option-Right Arrow to walk through the page. If the experience feels broken within the first ten seconds, the site is not accessible — no matter what the compliance badge says.

The Seven Silent Failures That Block Visually Impaired Users

These are the failures we find on almost every site we audit. Automated tools flag the first two. The other five require a human with a screen reader.

1. Images with decorative or duplicate alt text

Scanners check whether an image has alt text. They cannot judge whether that alt text is useful. A product photo labeled "product-image-final-v3.jpg" passes automated tests and fails every real user. Decorative images should carry an empty alt attribute so the screen reader skips them. Informational images need a description that matches what a sighted person would learn from the visual.

2. Form inputs without programmatic labels

A placeholder is not a label. When a visually impaired user tabs into an empty email field, the screen reader should announce "Email, required, edit text." If the form relies on placeholder text only, the user hears "edit text" with no idea what the field wants. Every input needs a real label element, with the for attribute matching the input's id.

3. Buttons and links built from non-semantic elements

A clickable div with a JavaScript handler looks like a button and behaves like a button for a mouse user. For a keyboard or screen reader user, it is dead code. The element never receives focus, never announces as a button, and never responds to the Enter or Space keys. Use the correct tag. When the visual design prevents that, add role="button", tabindex="0", and key handlers — but the right answer is almost always to use a real button.

4. Heading hierarchy that lies

Screen reader users navigate by headings the way sighted users scan with their eyes. They press H to jump from H1 to H2 to H3 through the page. When a site uses headings for visual sizing — an H4 for a small-looking title, an H2 skipped because the designer wanted different spacing — the outline becomes unreadable. A blind user cannot tell what is a section, a subsection, or a sidebar. Heading order has to reflect document structure, not font choice.

5. Focus states removed or invisible

A surprising number of sites still ship with outline: none in their CSS reset. For a sighted keyboard user with low vision, that removes the only signal showing where they are on the page. Every interactive element needs a visible focus indicator with at least 3:1 contrast against its background. The WCAG 2.2 focus-appearance criteria now make this explicit.

6. ARIA used to patch broken markup

ARIA attributes were designed to enhance semantic HTML, not replace it. When a site layers aria-label, role, and aria-hidden on top of incorrect markup, the announcements often conflict. A screen reader might announce a button twice, skip it entirely, or say something that contradicts what is on screen. The WAI-ARIA spec states this plainly: no ARIA is better than bad ARIA.

In our audits, sites that added ARIA attributes without testing them with a screen reader scored worse on real-world accessibility than sites with no ARIA at all. The markup lied, and the screen reader repeated the lie.

7. Dynamic content that never announces

When a user submits a form and a success message appears, a sighted user sees the green banner. A blind user hears nothing unless the developer added aria-live to the region that changes. Cart updates, filter results, validation errors, loading spinners, and toast notifications all need live regions. Without them, the page changes in silence and the user is left wondering whether anything happened.

The Fix Order That Actually Works

Accessibility remediation done badly makes things worse. A site with half-correct ARIA is louder, more confusing, and harder to use than a site with none. The order matters.

1. Start with semantic HTML. Replace clickable divs with buttons and links. Give every input a label. Use headings for structure, not styling. This step alone fixes 40 to 50 percent of typical failures.
2. Fix the keyboard path. Tab through every page. Every interactive element should receive focus in a logical order, with a visible focus ring, and work with Enter or Space. If you cannot complete a task using only the keyboard, a visually impaired user cannot either.
3. Write real alt text. Go through every image and ask what a sighted user learns from it. That is the alt text. Decorative images get alt="". Complex images like charts get a short alt plus a nearby text description.
4. Add live regions for dynamic content. Any part of the page that updates without a full reload needs an aria-live region so screen readers announce the change.
5. Test with a real screen reader. NVDA is free. VoiceOver ships with every Mac. Spend thirty minutes walking through your top three conversion paths. You will find more issues in that half hour than in a full day of automated scans.

Why Overlay Widgets Do Not Solve This

The pitch is tempting. Drop one line of JavaScript, get a compliance badge, skip the remediation work. Overlay vendors market this aggressively. Accessibility specialists and advocacy groups have been warning against it for years — and the courts are catching up. Federal complaints against overlay-using sites have continued to climb through 2024 and 2025, and judges increasingly treat the widget as evidence that a business knew about accessibility requirements but chose the cheapest path rather than the correct one.

Overlays cannot restructure your HTML. They cannot add labels the server never rendered. They often conflict with the user's own screen reader settings, making the experience worse for the people they claim to help. The overlayfactsheet.com project, signed by hundreds of accessibility professionals and disabled users, documents the technical and ethical problems in detail.

Building Real Website Accessibility for Visually Impaired Users

Genuine accessibility is not a plugin. It is a build decision — how the site is structured, how forms are marked up, how headings are ordered, how dynamic content announces itself. Done at the design stage, it adds almost nothing to the timeline. Done retroactively on a broken site, it can require rebuilding major templates from scratch.

That is the case for building accessibility in from day one. At Revenue Group, every site we ship starts with a semantic HTML baseline, gets tested against WCAG 2.2 AA with real screen readers — NVDA on Windows and VoiceOver on macOS and iOS — and documents the results in a short compliance file you can hand to your legal team if a complaint ever arrives. No overlays. No badges that do not mean anything. Just a site that works for the roughly one in twelve American adults living with a vision condition that affects their daily web use, according to CDC figures.