Often when I talk to clients, I am asked the following question: “Can we track how many users with disabilities access our site?”. The question itself is always asked with good intentions. The client wants to be able to provide an improved experience for persons with disabilities. Here’s my answer to a recent similar query:
From a technical standpoint there’s no way to reliably tell what sort of device the user is on. This goes for both traditional and mobile devices. I wrote an article about gathering usability data from server log files back in 2007. Back when that article was written, JavaScript-based analytics systems were just starting to take off and their capabilities varied pretty significantly. So, I left those alone and concentrated on the server-based analytics side of things. Though the capabilities of current analytics applications are much better than they were at that time, most of my arguments in that article are as valid today as they were then.
One of the things I didn’t mention in that article is that it is also possible for the user to falsely identify what device they’re using. In fact, back in the days of the browser wars in the early 90s, Microsoft intentionally faked the user-agent string to mimic Netscape. Today you can alter your user-agent string in Opera by going to ‘opera:config’ in the address bar and adjusting the settings there. Other browsers like FireFox and Chrome have extensions that can allow the user to switch the user-agent string. All of that, however, is really pedantic. The majority of people don’t alter their user-agent string, so for practical purposes, the user-agent string can reliably tell you the Operating System & version, Browser & browser version. This is all sent by the user’s computer during the negotiation between the site’s server & the user in HTTP.
Unfortunately, when it comes to accessibility, there’s little you can really tell from the user-agent string in your analytics. Assistive technologies aren’t user agents, so no information about them is sent via that negotiation. There are a few things you can possibly do with JavaScript, though I’ve never personally tried them.
- You can detect whether images are disabled.
- You can detect high-contrast mode (Windows only, as far as I can tell)
- You can detect if font-size has been enlarged.
- You can detect the visible viewport size.
- You can detect if the user is using only a keyboard to navigate
All of these are methods that ostensibly could help you to detect and personalize an experience for low vision users. This doesn’t help, however, if the low vision user has something like a magnifying screen attached to the physical monitor. When it comes to blind & motor impaired users, the latter ability to detect if the user is using only a keyboard to navigate may be useful but may be too expensive, from a programming perspective, to be very useful.
There’s apparently a way to detect screen readers using Flash. This would use Flash & ActionScript to detect an MSAA-enabled assistive technology. Theoretically, you could insert a very tiny (possibly even hidden in some way) Flash movie which takes that information and does something interesting using AJAX. This method isn’t quite reliable, either. This would work with JAWS, NVDA, Window-Eyes, most Dolphin products, and ZoomText. But this is far from a complete list of assistive technologies and doesn’t include VoiceOver, Dragon Naturally Speaking, or the dozen or so other screen magnifiers, screen readers, and voice input systems that compete in the market against these more well-known examples.
Finally, there’s the question of ethics surrounding detecting users with disabilities. Persons with disabilities are a protected class according to ADA and similar anti-discrimination laws worldwide. Users may be highly resistant to having their disabilities identified as they go throughout the web. Most persons with disabilities would really just rather that the Web just work for them. Attempts in the past, by Google and Amazon for instance, to create alternative interfaces for persons with disabilities has been met with significant resistance. Amazon, for instance, abandoned their “accessible” version and integrated many of their improvements into the main Amazon experience.
The sad reality is that Web accessibility is still pretty dismal, overall. Our internal research shows that an average of 11 images per page have no alt text and an average of 24 links per page have meaningless link text (like “click here”, “more”, “read more”, etc.). Global average error density is 16%, meaning that 16% of the code on the web has some sort of automatically detectable accessibility problem. That doesn’t count the errors that can’t be detected automatically. Despite this, persons with disabilities don’t want any special alternatives, they want the regular stuff to just work for them.
In the end, truly detecting the usage of persons with disabilities is going to be nearly impossible. The effort expended to somehow detect and track the usage patterns of persons with disabilities in order to create a so-called “enhanced” experience would be better spent making the regular site better. Accessible design is good design and when done right can improve the experience for everyone.