Analytics Tools Can't Track Screen Readers — And Shouldn't

December 8, 2021

When beginning an accessibility initiative, there’s a strong temptation to collect and analyze data. Does your website have any users with disabilities, and if so, how many? What assistive technologies do people use when accessing your website? What percentage of your visitors use screen readers — software that converts text to audio or or braille output — and how can you improve their experiences? 

Data collection is an important part of web development, and we understand why these questions might seem beneficial. As we’ve pointed out in other articles, all websites that receive regular traffic have users with disabilities. About 1 in 5 adults in the U.S. live with some form of disability or condition, so if your website doesn’t have users with disabilities, you’ll need to figure out why. Analytics tools can generate reports about user behavior at scale, which could generate helpful insights.

However, collecting detailed usage data about specific types of assistive tools can introduce legal and ethical concerns. Currently, website analytic tools can’t determine whether or not a person is using a screen reader, and major tools like Google Analytics have no plans to introduce such tracking capabilities. In this article, we’ll explain why analytics tools have this limitation (and why that probably won’t change).

Screen readers don’t provide user agent strings

When web browsers access websites, they send User Agent (UA) strings when making requests. UA strings contain basic information about the user, which can help the website’s server deliver an appropriate version of the requested content.

However, UA strings are limited to information perceptible to the browser such as the browser’s version and operating system. If the user’s screen reader is part of the browser application, this information could be theoretically included as part of the UA string — but currently, web browsers don’t include this information in their requests.

Additionally, most screen reader programs run separately from web browser applications. According to a survey from WebAIM (Web Accessibility In Mind), the two most popular screen readers are NVDA and JAWS. About 80% of survey respondents identified one of these two programs as their primary desktop/laptop screen reader.

If the user’s screen reader operates separately from the web browser, the browser can’t recognize whether the screen reader is running. Even if browsers suddenly began including screen reader usage in UA strings, they wouldn’t be able to report that information reliably.  

Related: Can You Use Google Analytics to Find Accessibility Issues?

Detecting screen reader usage without user consent raises ethical issues

Apart from the technical challenges, screen reader tracking would put sensitive user data at risk. In the aforementioned WebAIM survey, 39.2% of regular screen reader users said that they’d be “very comfortable" with allowing websites to detect screen reader usage, while 23.3% said that they’d be “somewhat comfortable.” But while most users aren’t opposed to screen reader detection, a sizable percentage of respondents said that they were uncomfortable with the concept.

Designers and developers often have excellent intentions when attempting to collect data about people with disabilities — typically, their goal is to find accessibility barriers and remove them. However, the data could be used for unethical and potentially illegal purposes. For example, job application portals could track disability status, then refuse candidates who might ask for accommodations. A healthcare company might monitor screen reader usage and adjust premium quotes based on the results. 

Of course, these scenarios are completely hypothetical, since web browsers aren’t capable of reporting screen reader usage. That’s unlikely to change in the near future. Still, it’s important to remember that by tracking assistive technology usage, you’re also tracking disability status — that information should only be shared with consent.

Screen reader detection is currently impossible, but developers haven’t stopped looking for ways to collect data 

At scale, insights about assistive technology usage could help people design better websites. However, users must be informed when they’re providing sensitive information. That has led some developers to come up with novel ways to ask users to allow behavior tracking via tools like Google Analytics.

On an analytics forum on Reddit, one developer shared a potential approach to screen reader detection:

Start with a block of text content that's invisible to sighted users but will be read by screen reading software. The text asks the user to perform an action to confirm they're using a screen reader. Three quick taps of the keyboard perhaps. This action both fires an event to GA and drops a cookie preventing the message being read out loud again. As long as they have the cookie, any new visits could fire the event.

We appreciate this developer’s ingenuity, but we wouldn’t recommend this tactic. Depending on the implementation, a block of text that isn’t visible to all users could be considered a violation of Web Content Accessibility Guidelines (WCAG) 2.1 Success Criterion 1.4.3, “Contrast (Minimum).”  Additionally, some users browse the internet with high-contrast settings. These users would likely perceive the text intended for screen reader users — and if they’re not familiar with screen reader technology, they may become confused. 

Even if the text content was hidden in another way, requiring certain users to complete specific actions could negatively affect their browsing experience. A better tactic is to simply provide a feedback form or contact information for reporting issues as part of your website’s accessibility statement. 

Make sure your accessibility statement is linked prominently throughout your website. While you won’t collect data from all screen reader users, you’ll probably receive actionable feedback — and if you analyze that feedback as part of a greater accessibility initiative, you’ll be able to create a better experience.

Related: Getting Feedback From Users to Improve Accessibility

Take proactive steps to find and fix accessibility issues

Before spending too much time on data collection, we recommend taking steps to resolve common accessibility barriers that affect your audience. The WCAG framework provides the best approach for adopting an accessible mindset and remediating issues.

By conforming with WCAG standards, you can provide a better experience for your entire audience including people who use screen readers and other assistive technologies. To get started, download our free website accessibility checklist, which utilizes concepts from WCAG, or visit our Compliance Roadmap for more accessibility resources.

Receive an industry accessibility analysis of your website

Recent posts

Making Online Forums More Accessible

January 17, 2022

How Accessibility in the Web Development Process Saves Time

January 14, 2022

Web Accessibility Lawsuits Dramatically Rose in 2021. Here’s Why.

January 12, 2022

Not sure where to start?

Start with a free analysis of your website's accessibility.

GET STARTED