Search form

How do you detect a screen reader?

The short answer is that you can’t. At the time of writing there isn’t a way to reliably detect whether someone visiting your site is using a screen reader (or screen magnifier). You might have heard that Flash will do the trick, but that might not be quite the solution you’re expecting.

People often ask whether it’s possible to automatically detect screen readers or other access technologies. The thought is that it would make it possible to deliver content in a way most appropriate for the given audience. Whether this is adviseable or not is a discussion for another day. For the time being at least, it’s a moot point in any case.

Screen readers (or magnifiers) don’t have user agent strings of their own. They work on top of the browser, so as far as your website’s concerned it’s dealing with the browser and that’s that. Well…. Almost.

Several Windows screen readers (and magnifiers) make use of the Microsoft Active Accessibility (MSAA) layer. It’s an API that enables access technologies to interact with standard and custom UI objects. It’s the MSAA layer that’s the basis of the Flash technique you’ve heard about.

Apart from the (obvious) fact that you need Flash to begin with, this technique is completely indiscriminate. It can only detect applications that use MSAA. It can’t tell the difference between a screen reader, screen magnifier, or a speech recognition application (and if you’re thinking about automatically serving up tailored content that’s a train crash waiting to happen)!

It's also a Windows based solution, completely oblivious to the growing numbers of screen readers and magnifiers used on Linux, Mac and other platforms. Another point worth noting is that not all Windows based screen readers use MSAA to begin with.

So if you were hoping to discover how to detect screen readers and other access technologies, I'm sorry to disappoint. In the meantime, your best bet is to stick to well structured, standards compliant and inclusive content delivery!

Share this article

Article tags

About the Author

8comments

Submitted by lwatson on Wed, 18/05/2011 - 10:50

We're just trying to keep you on your toes Denis!

You're right about the potential back step something like this could represent though. Generally speaking, I'm more in favour of giving people choices about the way they consume content, not making those choices for them.

Fooled me for a minute there. Was wondering if you'd found a way to detect them. Kind of reassuring to see that it's not. Such detections would probably be a bad idea and mean a few steps backwards in accessibility and inclusion advocacy.

Couldn't agree more! Especially when most people actually have no clue as to what users really need or expect.

Submitted by Travis marasca (not verified) on Sat, 19/05/2012 - 00:23

a useful analytical trick is to make sure you track events used mostly by users of AT suck as skip nav

Submitted by lwatson on Mon, 21/05/2012 - 11:58

That's an interesting approach Travis.

I'd be cautious about using something like that as a reliable metric though. Skip links could indicate sighted keyboard only users as well as screen reader users for example.

Submitted by Gerry Hat (not verified) on Fri, 01/06/2012 - 03:29

I know this isn't the best practice, but as I use AJAX extensivly in my websites, in order to provide the screen readers something to "read" I added a

with the CSS set to make the text transparent.

As this won't be visable to the normal user, the AJAX pages are rendered normally. However if the visually impared user selects the anchor, it will disable the javascript httpRequest and render the entire page (just as if they had disabled javascript)

Léonie,
That is a good point to mention.
In these scenarios I consider keyboard-only users as potential persons with mobility impairments and/or screen-reader users (or computer professionals/developers that hate the mouse such as myself ;) )

I should have been more clear that it is not a metric to rely on for screen-readers, but useful to see who is choosing to operate your application with a keyboard, or keyboard-like device.