Screen Reader Compatibility: How to Test and Fix Your Website for Assistive Technology Users

A few years ago, I watched a blind user try to book an appointment on a client's website. The screen reader announced "clickable, clickable, clickable" — three unlabeled buttons in a row. She had no idea what any of them did, and gave up after ninety seconds. That booking form had passed every automated accessibility check we'd thrown at it. That experience changed how I approach screen reader testing — and if you've never navigated your own site with a screen reader, you're about to discover things that will keep you up at night.

Understanding Screen Readers: Not Just "Reading the Screen"

Here's a misconception I run into constantly: developers think screen readers literally read everything on the screen, top to bottom, like scanning a document. They don't. Screen readers build a parallel structure — an accessibility tree — from the DOM and ARIA attributes. They navigate by headings, landmarks, links, and form elements. They announce roles, states, and names.

When that structure is broken or incomplete, the experience isn't just "slightly worse." It's often completely unusable. A missing form label doesn't just look sloppy — it means a blind user literally cannot tell what information a field is asking for.

Three screen readers dominate the market, and each behaves differently enough that testing with just one gives you a false sense of security.

NVDA (Windows, Free)

NVDA is the screen reader I recommend starting with, and not just because it's free. It's the most widely used screen reader among actual users according to WebAIM's annual survey, and it pairs best with Firefox. The learning curve is real — expect to spend an afternoon just learning the keyboard shortcuts — but the payoff is enormous. Download it from nvaccess.org, put on headphones, and start with Insert + Down Arrow to read continuously.

JAWS (Windows, Paid)

JAWS has been the enterprise standard for over two decades. It's more forgiving than NVDA in some ways — it'll try harder to make sense of poorly structured content — which is precisely why you shouldn't only test with JAWS. If your site works in JAWS but fails in NVDA, you haven't built an accessible site. You've built a site that one particular screen reader can compensate for. That said, many corporate and government users still rely on JAWS, so if your audience includes enterprise users, test with it.

VoiceOver (macOS/iOS, Built-in)

VoiceOver comes free with every Mac and iPhone, which makes it the screen reader your mobile users are most likely using. Activate it with Cmd + F5 on Mac or through Settings > Accessibility on iOS. VoiceOver with Safari is its own beast — it handles ARIA roles slightly differently than NVDA or JAWS, and some ARIA patterns that work everywhere else will trip it up. Always test VoiceOver with Safari specifically, not Chrome.

The Six Failures That Break Everything

After auditing hundreds of websites, I've found that the same handful of issues cause the vast majority of screen reader problems. Fix these six things and you'll resolve roughly 80% of the complaints your assistive technology users are silently having — or not so silently, if you're lucky enough to get feedback at all.

1. Missing or Useless Alt Text

Everyone knows images need alt text. And yet. I still find alt="image", alt="IMG_3847.jpg", and my personal favorite, alt="image of a picture of our team photo image" on production websites in 2026. The fix isn't complicated: describe the content and function of the image. If it's decorative, use alt="" (empty alt, not missing alt). There's a meaningful difference — missing alt causes the screen reader to announce the filename, while empty alt correctly tells it to skip the image entirely.

2. Heading Hierarchy Chaos

Screen reader users navigate by headings constantly. It's the primary way they scan a page, the equivalent of a sighted user's quick visual scan. When your headings jump from H1 to H4, or when you use H3 because it "looks right" visually but your document structure calls for an H2, you're essentially ripping pages out of a book's table of contents. Use headings in order. One H1 per page. H2s for main sections. H3s nested under their parent H2s. No skipping levels. For more on structural issues like this, check out our accessibility audit checklist which covers heading hierarchy in detail.

3. Unlabeled Form Fields

Every single input needs a programmatically associated label. Not a placeholder — placeholders disappear when you start typing, and many screen readers don't reliably announce them. Use a real <label> element with a for attribute matching the input's id. Or wrap the input inside the label. For complex form patterns, you might need aria-labelledby or aria-describedby — our guide on ARIA labels best practices covers when to use each approach.

4. Dynamic Content Without Live Regions

Does your site show toast notifications? Update a shopping cart count? Display form validation errors dynamically? If those changes aren't wrapped in an ARIA live region, screen reader users will never know they happened. The DOM changed, sure, but the screen reader's cursor is elsewhere on the page. Use aria-live="polite" for non-urgent updates and aria-live="assertive" for critical alerts. But be careful with assertive — overuse it and you'll interrupt users constantly, which is its own accessibility problem.

5. Custom Widgets Without ARIA Roles

That beautiful custom dropdown menu your team built from scratch with <div> elements? To a screen reader, it's just... text. Maybe some clickable text if you're lucky. Custom interactive components need proper ARIA roles (role="menu", role="dialog", role="tablist") and the corresponding keyboard interaction patterns. Honestly? Use native HTML elements whenever possible. A <select> is accessible out of the box. A custom dropdown built from divs requires dozens of lines of ARIA and JavaScript to achieve the same thing, and it'll still probably have edge cases you haven't handled.

6. Poor Color Contrast and Visual-Only Cues

"The error fields are highlighted in red" — great, but what does the screen reader say? If the only indication of an error is a color change, you've excluded not just blind users but also colorblind users. Always provide text-based cues alongside color. And while we're on the subject of color, make sure your contrast ratios meet WCAG standards — our color contrast WCAG guide walks through the specific ratios you need to hit for AA and AAA compliance.

A Practical Screen Reader Testing Workflow

Alright, theory is great, but how do you actually build screen reader testing into your development process without it becoming a bottleneck that everyone skips after two sprints? Here's the workflow I use with my clients, and it's survived contact with real development teams — which is the true test of any process.

Step 1: Automated First Pass

Run your pages through an automated accessibility checker first. This catches the low-hanging fruit — missing alt text, missing form labels, contrast issues. You can use our free accessibility checker to scan your pages for WCAG violations automatically. Do this on every deployment. No exceptions. It takes seconds and catches genuine issues.

Step 2: Keyboard-Only Navigation

Before you even turn on a screen reader, tab through your entire page using only the keyboard. Can you reach every interactive element? Can you see where the focus is? Can you operate dropdowns, modals, and forms? Can you escape modal dialogs? If keyboard navigation is broken, screen reader navigation will be broken too — and keyboard testing is faster to do. Make this part of your QA checklist for every new feature.

Step 3: NVDA + Firefox Walk-Through

Fire up NVDA with Firefox. Navigate the page using headings (H key), landmarks (D key), and links (K key). Fill out forms. Trigger dynamic content. Listen for anything confusing, redundant, or missing. The first time you do this, you'll be shocked at how different the experience is from what you see visually. That shock is the whole point.

Step 4: VoiceOver + Safari Check

Repeat the critical user journeys with VoiceOver on Safari. Pay special attention to any ARIA widgets — VoiceOver handles certain ARIA patterns differently, and this is where cross-reader bugs tend to hide. Mobile VoiceOver on an actual iPhone is even better if you can manage it, since swipe-based navigation reveals issues that desktop testing misses.

Step 5: Document and Prioritize

Not every issue is equally urgent. A missing alt text on a hero image is high priority. A redundant ARIA label on a decorative icon is low priority. Prioritize by user impact: can someone complete the core task on this page? If not, that's a P0. If the experience is degraded but functional, that's a P1. Cosmetic screen reader annoyances are P2.

ARIA: Powerful but Dangerous

I have a slightly controversial take on ARIA: most developers use too much of it, not too little. The first rule of ARIA is literally "don't use ARIA" — if a native HTML element does what you need, use that instead. Every unnecessary ARIA attribute is a potential point of failure, a thing that can go out of sync with the actual DOM state and confuse screen readers.

That said, there are situations where ARIA is essential. Custom tabbed interfaces need role="tablist", role="tab", and role="tabpanel" with proper aria-selected states. Modal dialogs need role="dialog" with aria-modal="true". Live content updates need aria-live regions. The key is using ARIA intentionally, not sprinkling it everywhere as a talisman against accessibility complaints.

For a deeper dive into getting ARIA right, take a look at our ARIA labels best practices guide — it covers the specific patterns that trip up most development teams.

Beyond Compliance: Why This Actually Matters

I'll be honest — if your only motivation for screen reader testing is avoiding ADA compliance lawsuits, you'll do the bare minimum and move on. And the bare minimum is... not great. It'll keep your legal team happy, probably, but it won't make your website genuinely usable for the roughly 8 million Americans who use screen readers.

The sites I've seen do accessibility well are the ones where someone on the team actually cares. Where a developer spent an afternoon navigating their own product with NVDA and came back saying "we need to fix this, it's embarrassing." That emotional connection to the problem drives better work than any compliance checklist ever could.

Does that mean checklists are useless? Of course not. But they're a floor, not a ceiling. Test with real screen readers. Listen to what your site sounds like. Better yet, include disabled users in your testing — they'll find issues in thirty seconds that your team missed in three months.