Access Technology Detection as an App Permission: A Possible Solution

Website code in multiple colors against a black background.

Access Technology Detection as an App Permission: A Possible Solution

“This app would like access to your location.”

“This website would like to access the microphone.”

We are all familiar with prompts like these when using various apps and websites on our devices. However, there is one piece of information we don’t often think about: whether an app or website is accessing if we're using a screen reader or not.

Access technology detection has been possible in programs for computers and apps for iOS and Android for a while, and now some are pushing for it to be available on the web.

For this discussion, I will use the term "access technology detection" to refer to an app or website’s ability to detect if any access technology is in use and potentially modify the user’s experience based on this knowledge. I will use "screen reader detection" when discussing implications of detecting screen readers specifically.

Detecting if a screen reader is in use can let apps provide improved functionality when screen readers are running. Providing spoken messages for events, surfacing text data instead of graphs or charts, etc. can all be done with screen reader detection. Unfortunately, it can also be used improperly, hiding functionality, presenting simplified or limited versions of interfaces, and more.

If access technology detection appears on the web, many are concerned that it would lead to developers causing more problems than without this capability. There are also privacy and analytics implications for both sides, which will only be magnified if access technology detection comes to the web.

The debate has been around for a while, but one solution I haven’t really seen discussed is access technology detection as a permission. This could allow users to explicitly approve each app, and app developers could be required to disclose when this will block functionality. This could also be applied to websites.

Access Technology Detection: Pros

When programs can detect if access technology is running, they can provide useful functionality that they otherwise couldn’t. The Zoom conferencing software sends alerts about people entering or leaving a meeting, chat messages, etc. directly to screen readers to provide increased accessibility for blind users. Many other programs send information directly to screen readers, Twitter clients, games, book readers, and more. On mobile, screen reader detection provides benefits such as direct touch, a feature of iOS which lets apps dedicate a portion of the screen to ignore VoiceOver input for things such as signature panels or certain games. On mobile, access technology detection could also be used in concert with other accessibility features to do things like auto captions in various apps, reorganize layouts to make them easier for switch users, and more. Another use for access technology detection could be to indicate when things aren’t accessible. While most people don’t like admitting something doesn’t work, it could be very useful to know for example if a certain feature of an app doesn’t work with screen readers yet, and when the developers expect it to be fixed.

Data Collection and Analysis

Access technology detection can provide useful information for developers and testers. If a subset of users using a specific technology disproportionately abandon a task at a given point, that may be an indication that further work is needed to improve the accessibility of that section. Just as many apps report the version of the operating system, and websites report browser information, reporting what access technology is in use can help companies determine which platforms and technologies to test with. There are quite a variety of access technology, operating system, and browser combinations out there, and companies can only test to a certain amount of them with their limited resources. Knowing which combinations are most popular in their market can help them target what most of their users are using. Lastly, access technology detection could allow companies to know what disability markets are using their product, and better target people with disabilities.

Access Technology Detection: Cons

As my grandfather likes to say: “All good things are abused.” There is certainly a lot of potential for abuse in access technology detection. It could be used to lock out features a developer thinks a person with disabilities wouldn’t use, or present limited or simplified versions of content. On the web, it could get even worse. The developer could simply put up a page directing users to call or email the organization, and direct all access technology users to this page.

There have been two notable instances of screen reader detection used improperly on mobile in the last few years. A few years ago, when Amazon was first adding Alexa capabilities to its mobile app, Amazon blocked this feature from even appearing if the app detected VoiceOver running. Adding to the problem, there was no indication that anything had changed. If the app was launched without VoiceOver running, the Alexa button appeared, but if VoiceOver was running, the old voice search button was visible. There was no way for VoiceOver users to get around this block short of launching the app with VoiceOver off and then turning it on. There were several articles posted and a number of people contacted Amazon. The Alexa feature was eventually brought back for screen reader users, but at the time it left a sour taste for many.

Much more recently, in May 2020, Facebook released the Avatar designer, a feature allowing the user to design a visual picture for their online profile. Unfortunately, Facebook made the decision to hide the Avatar designer from VoiceOver users, making the button disappear if VoiceOver is running while using the app. Once again, this has annoyed many in the blind community, but as of this writing the designer had not been made available.

While I can understand developers wanting to spare blind users from an inaccessible feature, simply hiding the feature from screen readers is the wrong way to go about things. The developer could easily include a popup message that informs users that the feature is not accessible, and provide the option to continue anyway or back out. This would inform users, and may even result in the developers getting useful feedback on how to make the experience better.

With the widely varying level of accessibility on the web, access technology detection in general, and screen reader detection in particular, has great potential for abuse. Developers could easily hide features that they think aren’t accessible or useful. They could redirect users to so-called “accessible” versions of the site without informing users. This alternate version could be an antiquated text-only site, have limited features, or even be a simple page giving the store’s phone number and hours, and directing the user to call.

Analytics and Privacy

One major concern of access technology detection is that a particular user may be identified as a person with a disability without their knowledge or approval. Many users are concerned that this could, for example, lead to discrimination in online job postings as the information could be stored by the company and associated with the user’s submission. Additionally, knowing what access technology a person uses is yet another piece of data companies could use for ads or even sell to third parties.

There is also potential for misuse on the analytics side of things. If a company notices that their site has only 0.5 percent of their users using access technology, they could decide that the market is too small to warrant spending resources on accessibility. Or, if access technology users drop out at a certain point in the process, a company could conclude that their product is not interesting to people with disabilities, instead of looking to see what accessibility issues might be causing issues with that step.

Doesn’t Exist on the Web

Currently, there is no existing method of asking the user for permission in apps, and access technology detection doesn’t exist at all on the web. Developing this capability on the web would require the cooperation of access technology and browser developers, and possibly require new technical standards from the W3C. This capability would provide no direct benefit to any of them, so getting meaningful movement on this may be difficult. That said, this is certainly doable if there is demand for it.

A Potential Solution: Access Technology Detection as a Permission

“This app (or website) wants to know what access technology is in use.”

A prompt like this could appear when an app or site wants to use access technology detection. This would alert the user, and give them a choice whether to allow or block the detection. If the user noticed an inferior experience, they could withdraw the permission from their operating system or browser settings, and go back to the unmodified experience. This would also solve the identification concerns. To go a step further, companies which request this information could be required to specify if there are major changes to the experience, and disclose how they are using this data in their privacy policies. This would be more enforceable with apps than on the web, however. Unfortunately, this would not solve all the analytics concerns, but I think education is the best solution for that.

Let’s Discuss

Do you think access technology detection is a good idea? What additional advantages or problems do you see with this strategy? Is there another strategy you think would work better? We want to hear your thoughts. You can contact me on Twitter at @karlb21 or email me at Follow the NFB on Twitter at @NFB_Voice. Follow the NFB on Facebook at

Further Learning

Here are some additional blogs, articles, and commentary discussing screen reader detection. The first resource listed, "Authentic Intelligence: A Blind Researcher Bringing Wisdom to the Future of Technology Innovations," was a speech given during our 2020 National Convention that focused on artificial intelligence.

—Karl Belanger