Screen Readers

[00:00:00]
>> So screen readers, they're a huge part of accessibility. Super cool that we have screen readers on our devices. So screen readers are a type of assistive technology or AT which I'll abbreviate here and there. In the world of accessibility, AT is just mentioned so much that you should know that that's what that stands for.

[00:00:24]
Screen readers allow people to both use websites and web applications and contribute to websites and web applications. There are blind developers. There's different ways that we can use software to consume software and to create software. So the whole the whole thing needs to be accessible if possible. And for many people with disabilities, screen readers are essential for navigating the day to day.

[00:00:50]
Mobile devices are amazing these days, and especially the iPhone has a really good screen reader built in. Using maps or checking your calendar, checking your email, chatting with a friend, taking pictures, blind people take pictures. There's all of these things that we use our devices for, you can do with a screen reader, especially on the iPhone, but Android devices do have a screen reader as well.

[00:01:20]
And it's not limited to blind people either, screen reading technology, which uses speech-to-text or text-to-speech. Yeah, text-to-speech, I think I wrote that backwards, can announce what is on the screen. And that can be useful for people who maybe have cognitive impairments or you just need more help. I've even used a browser extension, I think it's called Read Aloud.

[00:01:49]
If I'm just feeling really distracted and I have to read like a legal document or something, I will totally use a screen reader so that I just can't stop reading it. It'll read it to me. And I can see the screen, but it's still helpful to have it read aloud sometimes.

[00:02:07]
And so, we should consider that not all screen reader users are blind, or even fully blind. Some people use the screen reader even though they can see the screen, they're low vision. I think some of the techniques that I had seen for screen readers, just no one can ever see them like skip links.

[00:02:26]
There's a skip link I just fixed the other day that, no one can see a skip link, it's for screen readers users only. And I think that's a misconception that I hope to clear up that we should make keyboard interfaces that screen reader users can also use. So I have a graphic here of using VoiceOver for Mac, just navigating a photo website.

[00:02:52]
And so we can see the image of the cat, it's wrapped to the link, so the screen reader will announce what type of element we're on. And if there is content inside of it, it will tell us. So this is an image. It was a stock photo of a cat, so it says, free cat, feline, photo, and picture.

[00:03:11]
Maybe highlighting the alt text of this could use a little bit of help. Like, I don't know why it says photo and picture. But I think sometimes capturing things how they were created, seeing what it sounds like in a screen reader can be really helpful cuz you get more context of, that's why I shouldn't write the word photo in my alt text cuz it already is an image.

[00:03:34]
In this case, I think they had photo and picture and image. So we have to test it sometimes and figure out, well, what's gonna make sense in that context? So screen readers and how they work. Screen readers are both software and hardware, a lot of software that help people interact with the computer or mobile device.

[00:03:59]
They convert text and graphics on the screen to speech or even braille output. So there's tactile refreshable braille that people can use as well, so it's like reading with your fingertips instead of your eyes and that's pretty cool. But that leverages some of these same APIs and a lot of the same accessibility techniques that we'll learn about.

[00:04:21]
The iPhone, as I mentioned, has an amazing screen reader built in called VoiceOver for iOS. Mac computers have VoiceOver built in as well. It is slightly different than the version on iOS, just for platform reasons. On Windows, users can take advantage of the built-in screen reader, Narrator, or you can install third-party software like NVDA or JAWS.

[00:04:46]
I like NVDA, it's free and open source and I have a virtual machine on my computer that I can run testing on my Mac. So when users turn on the device, the screen reader will take the input using the platform applications. So things like the settings app, you could read that aloud in your screen reader.

[00:05:08]
You can have it read out the web browser or YouTube on your iPhone or whatever application, this isn't limited to the web. It's kind of intuitive when you think about it, but just kind of getting to the basics here. And so it'll render that output aloud, or using the tactile device if the user has one.

[00:05:30]
And it is pretty amazing that our technologies work that way. I have some details in here, there's a link to read more about screen readers. There are some surveys from a group called WebAIM, it's Web Accessibility in Mind. And, do I have that link in here? I'm sure there's a link in here somewhere, but I'll show it to you just in case.

[00:05:55]
So WebAIM is a group from Utah, and they're amazing. They put out these surveys every couple of years about how people report voluntarily using different screen readers and browsers. And this is sort of our gold standard in terms of what we can reference for data. Cuz I mentioned we don't track screen reader users for privacy reasons.

[00:06:20]
But we do have the survey results that are shared widely every time they open up the survey for participants. It is a little bit biased in that it's heavy on North America for who's contributing to the survey. It's kind of technology professionals mostly, but it's still something, it's really helpful to have.

[00:06:44]
So if we scroll down here, we can see they include mobile screen readers, screen reader and browser combinations. So if you're on Windows, I mentioned analytics a little bit, which we can't track screen readers directly, but we can put analytics on our sites to see which browsers and platforms people are on.

[00:07:04]
So say you have a heavy Windows user base. JAWS and NVDA are the leading screen readers for, it looks like Chrome on Windows. And so you can learn details about how people actually use these combinations on here and that can help you narrow down what you're gonna test.

[00:07:25]
We can't test everything. I'm not gonna go fire up every single screen reader, I'm gonna have to prioritize. And sometimes you don't have the bandwidth to test as much as you would like, but that's why we use standards. And why we try to get the basics in so it will work reasonably well most places.

[00:07:46]
And then if we have a blocking issue or something, some unique combination that our customers are telling us is really important, we can respond to that particular feedback and make improvements. So a big piece of how this works, depending on what platform you're on, so I mentioned Windows and iOS and Android.

[00:08:09]
These platforms come with their own accessibility APIs. And this gets pretty geeky. And I like it. [LAUGH] So, there is an awesome link in here that I included. It's kind of been archived and kept around of how browsers work. It's fascinating, browsers are very sophisticated applications. They clean up a lot of our markup messes.

[00:08:35]
And so Browsers and our platforms, so MacOS in the case of my computer, or iOS or whatever platform you're on those API's and the browsers work together to basically make our rendered webpages. The accessibility information that we get out of those is harnessed using platform accessibility APIs. And so I mention these because there are subtle differences in different platforms.

[00:09:06]
If you test a user interface and a screen reader on iOS, and then you go test the same page, it's a responsive page probably, you go to test that same one in NVDA and Chrome on Windows. It's not gonna be exactly the same. So it's like the accessibility version of Pixel Perfection.

[00:09:26]
There's going to be slight differences, we have to embrace them. Just know that those APIs are what's gonna generate those changes. It's not you, you're not losing your mind, they really are different. Even from MacOS to iOS, so that's something to remember. And an example here is the ARIA has pop-up state.

[00:09:46]
It is an attribute that you can communicate like a custom drop-down or something. It has pretty wildly different results depending on what platform you're on, and we have to work with that, just something to be aware of. So another piece of this, part of what makes this all work is the accessibility tree.

[00:10:10]
And this is a structure kind of parallel to the DOM or the document object model. This is what all of the accessibility information on a page gets put into its own tree, its own structure. And screen readers and other assistive technologies leverage that structure. Some screen readers also look at the DOM, I know JAWS does on Windows.

[00:10:34]
Historically, they would do that to try and work around the lacking accessibility. But the accessibility tree is a thing. You will see it as we get into debugging, and I'm doing a workshop on enterprise accessibility that will dive way deeper into the accessibility tree. So if you see that, you'll see it when we debug as I mentioned, that's what that is.

[00:11:00]
So we did look at WebAIM. How to prioritize, because there's so many combinations, you can't possibly test them all. So work with your teams to identify which browsers you need to test and then reference WebAIM's screen reader survey to know which screen readers are the most popular combinations.

[00:11:21]
On a Mac VoiceOver works the best with Safari. Safari is not usually prioritized in most Mac development environments that I've ever worked in. So it's kind of ends up being a special thing just to test so that VoiceOver will work. So maybe look at your site analytics, if you have them to see if people are really coming to the site in VoiceOver, it will work with Chrome.

[00:11:48]
You don't want to spend your time chasing down bugs in Chrome and VoiceOver that work in Safari. Talk about how you spend your time, you have to make those judgment calls and if it takes a little bit of time to get Safari to fix some display bugs so that it's not like full of broken windows.

[00:12:06]
I don't know if you know about broken window theory, but once there's a broken window, people will just abandon it. So if Safari looks janky no one's gonna use it. But if we kinda keep up on it, maybe it'll get used more and tested more. Because you could save yourself some time trying to, quote, fix things in VoiceOver and Chrome when they just work fine in Safari.

[00:12:31]
That's the thing but Windows, also, if you have any site traffic on Windows, which I mean, who doesn't? I think a lot of developers like I see all Macs in here. [LAUGH] But our customers and users are probably visiting on Windows. So we should have a process to make sure that we're testing and using a virtual machine is great.

[00:12:54]
There's also a service called Assistive Labs that you could check out to run screen readers in the cloud, on platforms that you don't necessarily use. But I do think the VM or virtual machine route is pretty great. And I have some more links here about how the browsers work.

[00:13:15]
My favorite Mozilla documentation for various topics. Yeah, so let's talk about how to enable these screen readers. So this page is full of cheat sheets and things that you would want to reference when you were in the act of testing. Starting with VoiceOver for Mac. And this is something I do all the time because I'm not a daily screen reader user.

[00:13:39]
You can watch me try to get better at it and I reference these documents. So this one is from Deque University, VoiceOver Keyboard Shortcuts on a Mac. I've even had this printer version on my workstation so I could reference it when I'm doing a lot of testing. But it is totally understood that you will have to brush up on these.

[00:14:04]
So VoiceOver, kind of, 10,000 foot view, it uses combinations of keys, starting with the VoiceOver key, which they say VO but it's actually control and option held together. So those modifier keys, you combine them with a bunch of other keys, that's a lot of commands to remember. So cheat sheet, you can cheat, you can reference.

[00:14:30]
I do, everyone does, I'd rather have to look it up and know what I'm doing. Than open Jira Issues or something when it's just operator error. That's a big part of getting into accessibility testing is sometimes the testers, they're doing their best, they care. If you're not a daily screen reader user, something might not even be an issue.

[00:14:53]
Or maybe it is an issue and you missed it, so there's a bit of a learning curve here. That is expected. So I'd bookmark that one. There's also similar cheat sheets for iOS cuz iOS is definitely a platform you should be testing if you have any mobile traffic.

[00:15:13]
It's pretty limited to Safari on IOS, Apple and Webkit have notoriously locked down the browser engine, so you don't have too much that you have to test. I wouldn't test Mobile Chrome or anything, cuz it's the same. But VoiceOver and Safari on IOS, if you have any mobile traffic, definitely worth trying, cuz it is a little different.

[00:15:37]
So, and then similarly, for Windows, we have some details on JAWS and NVDA. They work slightly differently. And so with VoiceOver, that 10,000 for view, it's It's like jumbles of keys, as I affectionately like to say. It's a lot of combinations of keys. Whereas with NVDA and JAWS, they work very similarly.

[00:16:04]
There is a totally different paradigm that you don't have to hold as many keys just because of the way it works. And this is something we'll get into in the enterprise accessibility workshop quite a bit. The sort of a gist of it is that there are different modes that depending on what type of element you're on, whether it's a form control or a paragraph, will change what key commands do what.

[00:16:32]
And so it's a little bit simpler sometimes to use. You just turn it on and tab around, navigate. We are going to try using VoiceOver as a bit of a demo. We could fire up NVDA, I do have it. We'll see if time allows, but just be aware that it's not gonna work exactly the same as VoiceOver does.

[00:16:57]
And then Android. So Android, their screen reader historically has been called TalkBack. I think they're just calling it Android Accessibility now. It's used by so many people. These devices are so popular that of course, there's people that use it. It's not as well-loved, not as well-tested, I will say.

[00:17:18]
It's probably the one that gets, if iOS accessibility gets missed, Android accessibility is definitely going to get missed. But if you have any Android users, it is worth checking out. I included some tips for testing with Android from Google. There's also a cheat sheet for using the TalkBack screen reader.

[00:17:40]
And there's some mobile testing tools that could be helpful. There's ones from Deque and from events there startup. So yeah, lots of different screen readers.