Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A developer's perspective: the problem with screen reader testing

jaketracey.com

Post reply on HN
Print view View original

31–40 of 54 posts

Re: A developer's perspective: the problem with screen reader testing

#31

Post by toast0 »

cosmotic wrote: post #29
jscholes wrote: post #17

Earlier quoted context omitted.

> 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 lik…

I wouldn't be surprised if some sighted users turn on the screen reader to get the 'worse' (read: superior) user experience. In some cases, the screen reader supported experience would be faster, easier to use, and more reliable.

It might well be superior when released, but will it continue to support everything, or will it sit around with no updates and miss out on new features, or simply stop working and have no one notice?

Re: A developer's perspective: the problem with screen reader testing

#32

Post by miki123211 »

jscholes wrote: post #22
mwcampbell wrote: post #20

Earlier quoted context omitted.

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?

> 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…

We also need to take into account the biases in this data. If a given website isn't screen-reader accessible, the screen reader usage statistics are going to be very low. This shouldn't be surprising to anyone, after all, why would blind people go to a website they can't comfortably use? Some developers would probably still use that data to explain why accessibility isn't important, though.

Regardless of that, as a blind person, I'm all for a flag that lets you detect screen reader usage. I believe a good compromise here is disabling this flag in private/incognito mode.

Re: A developer's perspective: the problem with screen reader testing

#33

Post by miki123211 »

> According to the latest WebAIM Screen Reader User Survey, when it comes to desktop screen reader usage, JAWS and NVDA are practically equal in usage, with around 40% of respondents reporting that they use one or the other.

I wouldn't take this data too seriously. The WebAIM user survey is only available in english, and usually filled by tech-savvy blind users who are part of the blind community and are told about it.

At this point, JAWS is mostly used in corporate environments in the United States, mostly due to the number of scripts already written for it, a business-friendly (non GPL) license, and easy enforcement of restrictions given by IT, which are features that NVDA doesn't provide. Some countries give out JAWS for free to their blind residents, so the number of JAWS users there is probably going to be pretty significant too. However, in most parts of the world, NVDA is the screen reader most people use. As a person living in eastern Europe, with many friends from around the world (including the U.S.), I know exactly two people using JAWS as a daily driver.

Re: A developer's perspective: the problem with screen reader testing

#34

Post by miki123211 »

One interesting fact to note, that WebAIM doesn't reflect at all, is the recent rise in usage of Chinese screen readers. ZDSR for Windows is still an insignificant and meaningless minority, but I'm not sure how long it's going to remain that way, considering it hasn't been available outside of China for very long. However, Commentary for Android is getting some significant usage, particularly in poorer countries where Android is the only thing most people can afford. It offers superrior experience and performance to Talkback, and isn't prohibitively expensive, so it's getting some popularity.

I wouldn't worry about testing with those screen readers for now, as there still aren't that many people using them, but it's something worth looking out for in the future.

Re: A developer's perspective: the problem with screen reader testing

#35

Post by robin_reala »

miki123211 wrote: post #34

One interesting fact to note, that WebAIM doesn't reflect at all, is the recent rise in usage of Chinese screen readers. ZDSR for Windows is still an insignificant and meaningless minority, but I'm not sure how long it's going to remain that way, considering it hasn't been available outside of China for very long. However, Commentary for Android is getting some significant usage, particularly in poorer countries wher…

Thanks for this info, it was the first time I’d run across either of them.

Re: A developer's perspective: the problem with screen reader testing

#36

Post by anoncake »

jscholes wrote: post #22
mwcampbell wrote: post #20

Earlier quoted context omitted.

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?

> 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…

What if screenreaders randomly switched between revealing and hiding themselves? Developers would get statistic but couldn't deliver a different UI to screenreader users.

Re: A developer's perspective: the problem with screen reader testing

#37

Post by bryanrasmussen »

toast0 wrote: post #15
mwcampbell wrote: post #6

> 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 blin…

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.

well, the fact is the use of a screen reader (or at least most) can be detected relatively easily by having an element in the screen reader flow that is hidden from sighted users, and if you wanted for extra surety having an element that will be interacted with by anyone accessing the page - but that is hidden from screen readers but available to sighted users.

detecting interaction with visually hidden element, but no interaction with visually shown element, can be registered as screen reader. Obviously this can also happen with bots, but probably you would prefer to register the bot as screen reader rather than to try to filter them out and inadvertently filter out a screen reader (which can often happen with bot filtering strategies anyway)

Re: A developer's perspective: the problem with screen reader testing

#38

Post by gampleman »

mwcampbell wrote: post #6

> 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 blin…

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).

Re: A developer's perspective: the problem with screen reader testing

#39

Post by Vinnl »

There are a number of browsers that run in Docker and that I can remote control (using Selenium, Playwright, Puppeteer or whatever) in my CI systems to run at least some smoke tests, making sure that basic features are available.

Does anyone know if something like that is available for screen readers - at least for a free and open source one?

Post reply on HN