A developer's perspective: the problem with screen reader testing
1–10 of 54 posts
Re: A developer's perspective: the problem with screen reader testing
#2In 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.
Re: A developer's perspective: the problem with screen reader testing
#3I’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.
Re: A developer's perspective: the problem with screen reader testing
#4In 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.
They do! Not fully optimized for developers perhaps, but check out "Speech Viewer" in NVDA and the "Braille Viewer" and "Speech History" in JAWS. This guide has some screenshots:
https://www.accessibility-developer-guide.com/setup/screen-r...
Re: A developer's perspective: the problem with screen reader testing
#5FYI: There is a small, low traffic group for blind developers: https://groups.google.com/g/blind-dev-works
I'm one of the co-owners.
Re: A developer's perspective: the problem with screen reader testing
#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 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.
Re: A developer's perspective: the problem with screen reader testing
#7> 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 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.
Re: A developer's perspective: the problem with screen reader testing
#8In 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.
They do! Not fully optimized for developers perhaps, but check out "Speech Viewer" in NVDA and the "Braille Viewer" and "Speech History" in JAWS. This guide has some screenshots: https://www.accessibility-developer-guide.com/setup/screen-r...
Also Narrator's developer mode, which you can toggle with Control+Narrator+F12 (where the "Narrator" key is either Caps Lock or Insert).
Disclosure: I used to work on the Narrator team at Microsoft.
Re: A developer's perspective: the problem with screen reader testing
#9> 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…
> 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.
Re: A developer's perspective: the problem with screen reader testing
#10I’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.
Yes, developers should be responsive to feedback, and especially so when it comes to accessibility, but I'm not sure I'm entirely comfortable with the idea of relying entirely or primarily on unpaid work for an entire area of testing.
Of course, it always depends on the overall funding situation of the app, but if funding exists, then I think AX testing should be paid like the highly qualified work it is.