A developer's perspective: the problem with screen reader testing • Hacker News Board

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

#21

Post by jimmaswell » Thu, Jan 07, 2021, 3:56 AM UTC

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.

Do you also take exception to braile translations replacing "red button" with "third button down"?

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

#22

Post by jscholes » Thu, Jan 07, 2021, 3:59 AM UTC

mwcampbell wrote: post #20

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…

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

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

#23

Post by jscholes » Thu, Jan 07, 2021, 4:07 AM UTC

jimmaswell wrote: post #21

toast0 wrote: post #15

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 and auditing and testing to confirm. Separate, but equal isn't equal.

Do you also take exception to braile translations replacing "red button" with "third button down"?

> Do you also take exception to braile translations replacing "red button" with "third button down"?

This is a different case for two significant reasons:

1. Utilising purely sensory references in web materials is a violation of WCAG success criterion 1.3.3, Sensory Characteristics (level A)[1]. Naturally, if you're physically brailling something, it's probably not web content but the point still stands: if your web page tells people to press the red button on the left it's not accessible to some.

2. By including alternative instructions in some form/format (or just making them inclusive from the start), you're not asking anybody to out themselves as having a permanent or circumstantial disability. You're just preparing for the case that they do. This is assuming the alternative option is available to everyone (e.g. on a web page or as a physical braille sign), rather than as something that is locked away and must be explicitly requested.

[1] https://www.w3.org/WAI/WCAG21/Understanding/sensory-characte...

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

#24

Post by pabs3 » Thu, Jan 07, 2021, 4:17 AM UTC

jscholes wrote: post #16

detaro wrote: post #2

In addition, I wish screenreaders had a text mode, where they print what they say and maybe provide cues on possible actions. Actual screenreader users work with astonishing speaking speeds and great memorization of commands, but without the experience a bare-bones but more visual interface would likely be easier to use.

> In addition, I wish screenreaders had a text mode, where they print what they say and maybe provide cues on possible actions. NVDA, mentioned prominently in the article as a free and open source screen reader, has a floating-window-style speech viewer. I sometimes use it when demonstrating a screen reader user's experience of a particular component when asked to share my audio, because slowing down the screen reade…

BTW, NVDA are hiring (in Australia) at the moment:

https://www.nvaccess.org/category/careers/ https://news.ycombinator.com/item?id=25639590

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

#25

Post by jareds » Thu, Jan 07, 2021, 4:56 AM UTC

jscholes wrote: post #18

User23 wrote: post #3

I’m absolutely certain there are plenty of NFB members who will gladly provide free screen reader accessibility testing for apps they use if the developer is responsive to feedback.

> I’m absolutely certain there are plenty of NFB members who will gladly provide free screen reader accessibility testing for apps they use if the developer is responsive to feedback. You could be right, but keep in mind that this may not significantly lower the amount of time required for developers to understand and remediate problems. Users have wildly differing levels of technical experience, so you may end up wi…

As a totally blind back-end developer I'm sure I'd be one of those people. If I'm doing accessibility testing for development tools my thoughts are probably worth while. If I'm doing accessibility testing for a bank my thoughts are probably less valuable. Unless it's horribly broken I'm tech savvy enough to usually get by. I don't expect all blind people to have 20 years of programming experience and the general technical aptitude that comes along with that.

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

#26

Post by forgotmypw17 » Thu, Jan 07, 2021, 5:17 AM UTC

If you design your website simply, you don't need to know that the user is using a screen-reader, nor what other strange situation that you'd never even imagined or accounted for may be happening. They'll be able to use it either way, because you made it universally accessible, rather than covering certain classes or cases individually.

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

#27

Post by defanor » Thu, Jan 07, 2021, 6:11 AM UTC

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

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

#28

Post by jacobtracey » Thu, Jan 07, 2021, 6:21 AM UTC

mwcampbell wrote: post #19

Forgive the second top-level comment, but I have some thoughts on Narrator and Edge. Disclosure: I worked on the Windows accessibility team at Microsoft during the transition from EdgeHTML to Chromium, and as a third-party screen reader developer before that. But I won't divulge anything confidential here. It probably comes as no surprise that EdgeHTML and Chromium have completely different accessibility implementati…

I did a bit more reading and noticed in the WebAIM stats that Narrator usage is indeed on the rise. Given that it is included in the OS, I would hope that it ends up as the defacto standard in much the same way as VoiceOver is for macOS.

Really interesting to hear some of the technical details from someone that worked on it - thank you!

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

#29

Post by cosmotic » Thu, Jan 07, 2021, 6:48 AM UTC

jscholes wrote: post #17

toast0 wrote: post #15

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 and auditing and testing to confirm. Separate, but equal isn't equal.

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

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

#30

Post by matsemann » Thu, Jan 07, 2021, 7:11 AM UTC

My biggest problem when using a screenreader for testing, is that my usage isn't the same as a blind person would use it. I mostly press "next sentence" or tab and am really slow. My testing is also biased by the fact that I know how it looks (what is on each page, which part I'm trying to reach).

When I visited a blind person to test for us at a previous workplace, I was astonished about what we found. It was very different from our own attempts. His voice-speed and navigation was so fast that the parts we felt were sluggish just took him a second to navigate through. He had other issues, however.