How to detect if a screen reader is active

Look, I'll be straight with you — figuring out if someone's using a screen reader? That's way harder than it should be. Modern browsers and OS makers have intentionally locked this stuff down. Why? Because they don't want people fingerprinting users or violating privacy. There's no magic JavaScript API or CSS trick that'll reliably tell you across every browser and device. But developers have gotten creative. You can infer things by watching how users behave, poking at assistive tech APIs, or sniffing out browser-specific signals. It's messy though.

Is there a reliable JavaScript API to detect screen readers?

Nope. Not a single one that works everywhere. WCAG and browser security folks actively discourage this whole idea — they're worried about tracking and fingerprinting. People used to check window.navigator or mess with msLaunchUri back in the Internet Explorer days, but that stuff is ancient history. Chrome, Firefox, Edge? They don't play along. These methods are basically useless now.

Can CSS media queries detect screen readers?

CSS can't directly detect screen readers. But here's the thing — some assistive tech like NVDA or JAWS might trigger certain CSS features like prefers-reduced-motion or prefers-color-scheme based on user settings. A lot of screen reader users turn on "reduce motion" to kill annoying animations. So you can use @media (prefers-reduced-motion: reduce) and guess. But it's not solid proof. Regular users might have that setting on too.

What is the focus trapping method to detect screen readers?

This one's all about watching how people navigate. Screen reader users bounce around with Tab, Shift + Tab, or arrow keys. Developers can listen for keydown events and track document.activeElement. If someone tabs through stuff in a straight line, maybe they're using a screen reader. Or maybe they're just a keyboard junkie. It's not reliable — standard keyboard navigation looks the same.

How can you use the Accessibility Object Model (AOM) for detection?

There's this emerging thing called the Accessibility Object Model. Lets you poke around the browser's accessibility tree. In some browsers you can check element.ariaActiveDescendantElement or look at role attributes to guess if assistive tech is running. But support is patchy. Honestly, don't use this in production. The smarter move? Just stop trying to detect screen readers. Build your site accessibly from the ground up with semantic HTML, ARIA labels, and keyboard navigation. Everyone wins.

Data table: Screen reader detection methods comparison

Checklist for accessibility testing without detection

• Use semantic HTML — <nav>, <main>, <button>. The real deal.
• Slap ARIA labels on interactive stuff.
• Make sure everything works with a keyboard.
• Test with actual screen readers. NVDA, JAWS, VoiceOver. Don't skip this.
• Inspect the accessibility tree in browser dev tools.
• Stop obsessing over detection. Build for everyone from day one.

Expert insights on screen reader detection

“Detecting screen readers is a privacy nightmare. Instead of trying to detect assistive technology, focus on making your website robustly accessible. Use progressive enhancement and test with real users who rely on screen readers.” — Léonie Watson, accessibility expert.

Frequently asked questions