Screen Readers Q&A

[00:00:00]
>> What's the difference between low vision and visually impaired?
>> Yes, so visually impaired is sort of an umbrella term that covers a lot of vision issues. Whereas low vision is more specific to someone not fully blind, but has enough of a vision impairment that affects their daily life.

[00:00:21]
I think there are some numbers around the stuff. So visually impaired would include people who are fully blind and low vision. Whereas low vision is a bit more specific, people who can see somewhat, and it's so different for every person.
>> How much should Devs use screen readers in their day-to-day job?

[00:00:43]
>> I would say regularly just so that you are actually doing it. It does take some practice. So it is a bit of a balance, you don't wanna sink a bunch of time into something that you might be uncovering things that are issues. Or I spoke to this a little bit earlier, where sometimes it's operator error, [lLAUGH] and something we think is an issue really isn't, or maybe there is an issue that we didn't find.

[00:01:11]
So I'd say you work it in your workflow, I mean, maybe once a week or just on a periodic bases, depending on are you working on the same feature for a long time? I think when you work on something, I don't know, if you're never gonna look at it again, but people use it, definitely, you have to test it when you have the opportunity to make changes.

[00:01:40]
If you're working on something regularly, I just built a feature that took me maybe a month, and so I had various aspects of this epic that I was working on. I tested at multiple steps of the way. So I'd say it's kind of a balance of testing it enough that you are familiar with it, but if you're not an accessibility specialist, you're probably not gonna do it every single time you sit down.

[00:02:12]
I would say what we go into in the next section with debugging, you would do a lot more. There's developer tools that we can use that will give us a pretty good idea of what the screen reader will read out. And those are just so much easier to work in your regular workflow, that I would say, reach for those first.

[00:02:33]
>> Is there something like cross browser testing, but for screen readers? How much should we put into testing our work against different screen reader technologies? Or is it enough to use something like the built-in Mac VoiceOver?
>> Yeah, so I do think that testing it on Windows screen readers is important, because depending on your user traffic, you could let that dictate some of how you prioritize.

[00:03:04]
Safari and VoiceOver work the best, but Safari is kind of a niche browser, unfortunately. I mean, it's not what we're often developing in. People are probably visiting your site more with Windows Chrome. Just a guess, it's probably not true across the board, but we want to be testing with screen readers on Windows because they do work so differently.

[00:03:28]
VoiceOver is great, I would definitely say if you could test it regularly, that'd be great. I think if you could only pick one to prioritize, I would honestly say Windows over VoiceOver just because of how many people use it. NVDA on Windows and JAWS, they work really similarly.

[00:03:50]
So you could probably just opt for NVDA, at least as a developer. I think for accessibility teams that are more specialized, they are going to be putting more resources and more time, more experts on testing various screen readers. Not everyone has an accessibility team, so I think you have to kind of pick what's the right balance of testing for you.

[00:04:15]
I did mention one tool earlier called Assistiv Labs. Let's pull that, it's assistive without the E. And so thinking of BrowserStack or something that's kind of cross-platform to test, that's sort of the goal of Assistiv Labs so that you can test with screen readers even if you're not using that platform.

[00:04:40]
So I would check that out kind of in this realm. It could be a service that could be a good tool for your team, it's pretty awesome. Is there any other questions?
>> Does it make sense to create alt text for galleries? Thinking something like carousel or image galleries script.

[00:05:05]
>> Yes, so we have images. I mean, if they're worthy of going into gallery, they should probably have some alt text, especially if those images are wrapped in links. So when we looked at the W3C's alt decision tree, that link that we pulled up earlier, they describe all of these different scenarios so you don't have to remember all of them.

[00:05:28]
But if those images are in links, we need something to give text to the links that are wrapping them. But even if they're just plain images in a gallery, if they're worth looking at, then they should have some alt text on them, I would say.
>> Many SEOs say that you shouldn't leave alt text blank.

[00:05:49]
Is there another way to have screen readers ignore the alt texts for decorative images?
>> Yes, I would be curious what they were basing that on. But sometimes we have to work with the advice that our marketing teams really insist on. So leaving the alt attribute blank, the attribute's present, but the value is blank, is the way that we learned earlier.

[00:06:15]
You could also have a screen reader skip over an image by putting a role of presentation on it. You could even put ARIA hidden of true on there, that's a pretty big hammer for a tool. I would ask the question of like, do we really need to do that?

[00:06:35]
Before we reach for ARIA for things, we wanna make sure that we absolutely need to because there could be other aspects. I don't know, it's a pretty simple one, so it might not be too complicated. But anytime you're like, maybe we could put some ARIA on it, you should caution, pause, do we really need to?

[00:06:55]
[LAUGH] But putting role presentation on it might be able to skip it. I guess I would be curious why we would need to.
>> So is it better to use tools like axe, WAVE, and Lighthouse, and maybe even voice control to test keyboard instead of VoiceOver for devs that are new to accessibility and don't really know much?

[00:07:20]
>> Yeah, so the question was about whether to use tools like browser extensions, which we're going to dive into a lot here in a minute. I would say those are a great starting point. So the screen reader, it's nice to fire it up, it's nice to know that it exists.

[00:07:37]
And you have to know kind of what we're trying to get to with the tooling. When we're using axe or WAVE, as you'll see what those are in a minute, we kinda wanna know what's the purpose. And so if you have at least tried out the screen reader, even if you do use the developer tools primarily, it's like, conceptually, you have to understand what we're trying to do.

[00:08:03]
And so it's hard to understand that without ever firing up a screen reader. But I think if you can get most of the way there and prevent some accessibility defects, as we call them, let's just call it what it is, they're defects in our projects. If we can prevent those from shipping by using developer tools, great, I think that's fine.

[00:08:24]
As we do it more and more, we should fire it up every now and then, fire up the screen reader. Finding that right balance of putting in enough time that it's worthwhile and useful is something that everyone is gonna be different at. I probably do it more than some other developers do, but yeah, I think, like I mentioned, conceptually, we need to understand what it is that we're trying to make.

[00:08:48]
What are we adding all this markup for? And yeah, so that's the goal.
>> And David in chat was just commenting that on his team, they use Assistiv Labs for the team, and then QA and our lead accessibility engineer as a Windows and Android device.
>> Cool, awesome.

[00:09:10]
So people using Assistiv Labs in the wild. And that is interesting to hear about how teams are structured. So for some teams, there are going to be accessibility specialists, that is a thing that people do. It is a little more rare, especially in today's market. I mean, I guess regardless of what's going on in the job market, it's helpful if a lot of us can sort of carry the weight of building accessible web pages.

[00:09:40]
And so we have to verify that somehow. And in the next section, I'm gonna show you kind of the workhorse tools of how you'll do that. But with or without accessibility specialists and accessibility teams, if we all did more [LAUGH] to make things accessible to prevent totally inaccessible things from shipping, I bet we would have an impact.

[00:10:02]
So that's my goal, is just to get all of us to participate, even if we're not experts in it.