6 ms·

> Sadly, there’s not currently any way for a developer to identify the type or version of a screen reader that is being used That's at least partly because th

> Sadly, there’s not currently any way for a developer to identify the type or version of a screen reader that is being used That's at least partly because there are some vocal blind people who don't want websites to be able to know that they're running a screen reader at all, for fear of discrimination. I believe that stance is misguided. I'll illustrate why with a story. A few years ago, my best friend, who is blind, was trying to do something on PayPal, and couldn't complete the task with his screen reader. I tried to do the same task, with the same screen reader, and didn't have any problem. So I figure we got caught in an A/B test or phased rollout. And it occurred to me that PayPal would never know that he failed to complete the process because he was using a screen reader. If we allowed websites to know what screen reader a user is running, they could collect useful data that could help them improve. And frankly, the problem that we actually have with accessibility is not willful discrimination, but indifference. P.S. It was a weird feeling to hear the name of a product that I developed from the ground up in the "What about ..." section heading. Yeah, I'm talking about System Access, the most obscure (and perhaps poorly named) screen reader mentioned in the article. No offense taken though; I understand where the author is coming from.

jacobtracey 6y ago
I completely agree with you. At the very least it could be a feature you opt in to. Would help a ton with the issue of fragmentation as well.
gitgud 6y ago
> there are some vocal blind people who don't want websites to be able to know that they're running a screen reader at all, for fear of discrimination This makes sense, it's probably not a good idea to give that information to the website. It would only make people using screen readers more vulnerable to scams. Similar to how "scam callers" work. If a "scam caller" rings someone and an older person answers the phone. The fact that they can hear an older person, means that they have found an easy target, and can use specific tactics to take advantage of them (techno jargon, etc..). If they don't have that information, then it's much harder for them to use specialised tactics to manipulate people.
- mwcampbell 6y ago
  I doubt that anyone would take advantage of the ability to automatically identify a screen reader visiting a website to scam blind people. In any case, I think that lack of usage data is a much bigger problem.
  - deleted 6y ago
    [deleted]
hunter2_ 6y ago
To say that it's fine to disclose the use of a screen reader because willful discrimination is not a problem we actually have -- that, if I'm using the phrase properly, begs the question.
toast0 6y ago
I can't imagine websites doing anything but dropping screen reader users into a separate experience; rather than doing the work to design for accessibility in all their experiences and auditing and testing to confirm. Separate, but equal isn't equal.
- jscholes 6y ago
  > I can't imagine websites doing anything but dropping screen reader users into a separate experience; rather than doing the work to design for accessibility in all their experiences I agree with this. I will say that developers who are 100% unwilling to entertain changes to their "main" UI to accommodate accessibility are in the clear minority. But even the most well-meaning devs and designers will ask questions like, "could we just do this for screen reader users ...?". It's a slippery slope from there, with technical debt, legacy implementation and ghetto user flows all the way down.
  - mwcampbell 6y ago
    Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps?
    - jscholes 6y ago
      > Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps? Quite possibly. But there is an argument for that being voluntary rather than mandatory, even if that decision is provided via a switch in OS-or-screen-reader-level settings. But then there are questions such as: - Should such a setting be switched on by default? - What sort of users are likely to enable/disable it? - If there is any correlation between level of technical skill and privacy awareness, will results be skewed towards the users with lower levels of technical knowledge? - If a product team uses the data to solicit feedback from users who are detected to be running an assistive technology, but quote "power users" unquote have turned off that detection, again, will that feedback be representative? Anecdotally, I will say that after working with some iOS development teams where this behaviour is natively available, cases which rely on an explicit detection of VoiceOver still seem rare. Whereas, use of features like accessibility label overrides without an explicit check are used a lot. On the other hand, it's becoming much more common to perform explicit checks for more visually-oriented accessibility features, like reduced motion or high contrast, some of which can even be carried out on the web now.
defanor 6y ago
I certainly had to tweak HTTP user agent headers in the past to get content out of some websites. IIRC Twitter (or possibly some other website(s)?), until recently, seemed to be somewhat usable without JS, but the content was covered and made unusable with a message about JS being required -- which isn't behaviour based on reported user agent capabilities, but still intentional breaking depending on them. It's not hard to imagine that some websites will decide to not support screen readers, and to block them completely and explicitly, to avoid related issue reports and complaints (again, as they do with JS, cookies, CSS). Or at least messages like "you need to upgrade to JAWS in order to access this website", since the website will be tested just with that. Actually I think varying behaviour depending on reported user agent was a source of frustration to users from the beginning. Maybe it'll turn out fine this time or in this case, but those concerns sound valid to me.
gampleman 6y ago
I think this lack of ability to distinguish screen reader users also comes with some serious drawbacks. I've been in situations (I do a lot of heavy data viz work) where providing alternative content for impaired users as well as graphical content for sighted users is a performance no go. If I could reliably detect which kind of content is preferred, then it would not be a problem. But if >90% of your audience is to suffer choppy frame rates (and 100% of your bosses) just to generate invisible content, the end result is that there is no alternative content (or crappy one: "A chart showing the relationship between instance count and cost" <- this leaves out all the interesting stuff).

jacobtracey 6y ago

I completely agree with you. At the very least it could be a feature you opt in to. Would help a ton with the issue of fragmentation as well.

gitgud 6y ago

> there are some vocal blind people who don't want websites to be able to know that they're running a screen reader at all, for fear of discrimination This makes sense, it's probably not a good idea to give that information to the website. It would only make people using screen readers more vulnerable to scams. Similar to how "scam callers" work. If a "scam caller" rings someone and an older person answers the phone. The fact that they can hear an older person, means that they have found an easy target, and can use specific tactics to take advantage of them (techno jargon, etc..). If they don't have that information, then it's much harder for them to use specialised tactics to manipulate people.

mwcampbell 6y ago
I doubt that anyone would take advantage of the ability to automatically identify a screen reader visiting a website to scam blind people. In any case, I think that lack of usage data is a much bigger problem.
- deleted 6y ago
  [deleted]

hunter2_ 6y ago

To say that it's fine to disclose the use of a screen reader because willful discrimination is not a problem we actually have -- that, if I'm using the phrase properly, begs the question.

toast0 6y ago

I can't imagine websites doing anything but dropping screen reader users into a separate experience; rather than doing the work to design for accessibility in all their experiences and auditing and testing to confirm. Separate, but equal isn't equal.

jscholes 6y ago
> I can't imagine websites doing anything but dropping screen reader users into a separate experience; rather than doing the work to design for accessibility in all their experiences I agree with this. I will say that developers who are 100% unwilling to entertain changes to their "main" UI to accommodate accessibility are in the clear minority. But even the most well-meaning devs and designers will ask questions like, "could we just do this for screen reader users ...?". It's a slippery slope from there, with technical debt, legacy implementation and ghetto user flows all the way down.
- mwcampbell 6y ago
  Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps?
  - jscholes 6y ago
    > Still, mainstream developers make decisions based on data. So if we want them to serve our community, shouldn't we help them by giving them data on how we use their sites and apps? Quite possibly. But there is an argument for that being voluntary rather than mandatory, even if that decision is provided via a switch in OS-or-screen-reader-level settings. But then there are questions such as: - Should such a setting be switched on by default? - What sort of users are likely to enable/disable it? - If there is any correlation between level of technical skill and privacy awareness, will results be skewed towards the users with lower levels of technical knowledge? - If a product team uses the data to solicit feedback from users who are detected to be running an assistive technology, but quote "power users" unquote have turned off that detection, again, will that feedback be representative? Anecdotally, I will say that after working with some iOS development teams where this behaviour is natively available, cases which rely on an explicit detection of VoiceOver still seem rare. Whereas, use of features like accessibility label overrides without an explicit check are used a lot. On the other hand, it's becoming much more common to perform explicit checks for more visually-oriented accessibility features, like reduced motion or high contrast, some of which can even be carried out on the web now.

defanor 6y ago

I certainly had to tweak HTTP user agent headers in the past to get content out of some websites. IIRC Twitter (or possibly some other website(s)?), until recently, seemed to be somewhat usable without JS, but the content was covered and made unusable with a message about JS being required -- which isn't behaviour based on reported user agent capabilities, but still intentional breaking depending on them. It's not hard to imagine that some websites will decide to not support screen readers, and to block them completely and explicitly, to avoid related issue reports and complaints (again, as they do with JS, cookies, CSS). Or at least messages like "you need to upgrade to JAWS in order to access this website", since the website will be tested just with that. Actually I think varying behaviour depending on reported user agent was a source of frustration to users from the beginning. Maybe it'll turn out fine this time or in this case, but those concerns sound valid to me.

gampleman 6y ago

I think this lack of ability to distinguish screen reader users also comes with some serious drawbacks. I've been in situations (I do a lot of heavy data viz work) where providing alternative content for impaired users as well as graphical content for sighted users is a performance no go. If I could reliably detect which kind of content is preferred, then it would not be a problem. But if >90% of your audience is to suffer choppy frame rates (and 100% of your bosses) just to generate invisible content, the end result is that there is no alternative content (or crappy one: "A chart showing the relationship between instance count and cost" <- this leaves out all the interesting stuff).