Live data from Hacker News

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

jaketracey.com

51–54 of 54 posts

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

#51
post #15

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

> Separate, but equal isn't equal.

The world of mobile web sites demonstrates that this swings both ways. Some web sites have mobile-specific interfaces that greatly enhance the experience when using the site on a small screen touch device compared to a large screen keyboard/mouse device. Wikipedia for example, the desktop interface is terrible on a phone and the mobile interface is terrible on a desktop. Obviously other sites are well known to have swung in the opposite direction and whichever variant is not their primary target is significantly worse.

I think that in a similar way the ability to serve specific content optimized for screen readers would allow those who care to deliver a much better experience, but likewise those who don't might make something worse.

---

Of course the simple web site purist in me wants to say that every web site should just stick to basic formatting and text-primary designs that work well in any browsers, but that idea is not just unrealistic thanks to marketing people but it would simply not work for so many modern sites and web applications.

I say the solution is the same as it's always been for when bad web sites do stupid things based on user agent or whatever else. Lie to them. As long as the screen reader can turn off the identifier tag it seems like the worst case outcome is a minor annoyance to have to blacklist that web site from receiving the tag.

--- edit: also a side thought, the things that make a screen reader work well also make it easier to separate content from ads, so there is an inherent commercial incentive for ad-supported content providers to only do the minimum legally required.

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

#52

Earlier quoted context omitted.

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…

> 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 This isn't true, at least not enough to be useful. The majority of screen readers present web pages in a kind of virtual buffer, which users can browse with the arrow keys and other shortcuts (e.g. H to jump by heading). In this mode, the…

I guess #3 explains my confusion, as whenever I use a screenreader it's for testing and I just tab through.

I suppose each screen reader then has its own hotkey shortcuts? Do you know of any resource that puts shortcuts of most popular screen readers together?

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

#53

Earlier quoted context omitted.

> 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 This isn't true, at least not enough to be useful. The majority of screen readers present web pages in a kind of virtual buffer, which users can browse with the arrow keys and other shortcuts (e.g. H to jump by heading). In this mode, the…

I guess #3 explains my confusion, as whenever I use a screenreader it's for testing and I just tab through. I suppose each screen reader then has its own hotkey shortcuts? Do you know of any resource that puts shortcuts of most popular screen readers together?

If you happen to be using Windows, Narrator has a well-written tutorial (no, I didn't write it) that goes into the most common shortcuts, and you can get a complete list with Narrator+F1 (the "Narrator" key is either Caps Lock or Insert). I believe VoiceOver on Mac also has a tutorial.

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

#54
post #31

Earlier quoted context omitted.

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?

In large, the reason the screen reader versions would exist is the threat of lawsuits due to the ADA. I work professionally in this realm and accessibility is a huge part of our development and QA process. A release doesn't go out unless thoroughly tested for accessibility. I presume that would just map on to the screenreader site forks.
Post reply on HN