Web Accessibility and Tools to Help

[00:00:00] Hey Paul, you remember that time you showed me how to use a screen reader and I found a bunch of bugs? Welcome to The Half Stacks with Paul and Steph. Your go-to podcast for tech jabbers. On today's episode... Accessibility. What is accessibility to begin with? The encompassment of pretty much any assistive technology and making sure that you can use a website or any type of application.

[00:00:23] So that could be something like keyboard navigation or what we're all mostly aware of when it comes to accessibility of screen readers. But it also includes things like being aware of, you know, a user who might be colorblind and the implications there. Or someone who has, like, limited mobility. It can affect how they use a website or application.

[00:00:50] And so basically, the reason that I care about it so much is when I was starting off in my career, I was on a project where we were doing a huge migration. And so we went from having a basically completely native built website.

[00:01:08] So very much traditional form fields, all, like, native browser tags to pretty much a lot of customized stuff. Not only that, the application was rendering on browsers, but also in our native applications web views.

[00:01:33] And so it made it a really complex migration for accessibility. So basically, when we went for our accessibility testing, everything blew up. We had so much that was custom, there wasn't much we could do. So six years ago, approximately six years ago, I had joined a team.

[00:01:59] And one of my first goals was to become an accessibility champion, right? Knowing zero things about accessibility. I had made the assumption, which I think most people make, which is accessibility is only about area labels. ARIA labels. ARIA labels.

[00:02:28] And image alt tags. And semantic HTML. Like, that is basically, like, I don't think I'm alone in that assumption. I think a lot of people are like, oh, yeah, if I just throw on an ARIA tag or whatever, it's fine. And as long as my image has, like, you know, alt tag, alt attribute to it, it's fine.

[00:02:57] How wrong was that assumption? Very wrong. So that's kind of where I was getting to, is that in this migration, basically, we took a whole bunch of native links and native buttons and turned them into basically divs that have, like, on-click handlers on them. Because of this, it didn't work on the native applications.

[00:03:25] So Android and iOS were completely not working. And then any type of screen reader interaction was gone. And so basically our accessibility testing team came in and was like, okay, here's the solution. And so it was basically a combination of putting, like, roll button on things, doing the ARIA label thing, along with putting tab index and a couple other decorators on it.

[00:04:21] Okay. So I think a user should go through them. Can it be inherently accessible? Or do you think accessibility work is something that is, like, it should be an effort on its own? It essentially has to be an effort on its own. Like, don't get me wrong. Like, if you're using proper DOM structure and making sure that, you know, whatever label is associated to your form field, you know, you're kind of winning half the battle there.

[00:04:52] But the problem is, is then you have UX comes in and, you know, they want this error message. And, you know, it's usually just, like, a red error message, right? Well, if it's just a red error message and it doesn't really say error for a person who's colorblind, they may not realize it's an error message. And so you have to go beyond just using the proper DOM structure.

[00:05:18] You actually have to learn a little bit about other people's interpretations of your UI. Okay. And so that way, just when you're taking in requirements, you could be like, hey, have you thought about this? Like, you might have an accessibility violation here. And so that way, you know, you're starting out at a good base level if your requirements, you know, basically take accessibility into concern.

[00:05:42] Another question I have is, is doing accessibility, creating a separate experience? Like, you can, like, high text, right, and have the screen reader read it out. Can accessibility be a separate experience? As in, it gives a visually impaired user more content or more context than it would someone that is not visually impaired?

[00:06:11] Or is it best practice to stick to the original experience as much as possible and just follow some rules? I'm very hesitant to go about the road of you can have one experience for a screen reader or any type of assistive technology user. And then a different experience for someone who's, you know, using traditional navigations.

[00:06:38] Mainly because it starts to go down the road of you potentially water down someone who's using assistive technology, so they're not getting as rich of an experience. And so basically kind of treats them separately. And that's not the way to go about it. What you want to do is you want to look at your UI and design it for anyone to use.

[00:07:03] You know, whether it's a case of someone who's using, you know, some sort of keyboard navigation or trackpad, tracking ball to navigate. Or if they're using screen reader, whatever it is, you create a uniform experience. So yes, for a screen reader, you might expose more visually hidden text to kind of represent what's happening on the screen.

[00:07:32] Let's say you have an image. You know, yeah, of course, you're going to have an alt tag on there or aria label to explain what that image is. Assuming it's not a decorative image. But basically, you want to kind of create a consistent experience no matter who the user is. So when it comes to accessibility, it generally falls into four categories. So there's visual needs, mobility, auditory, and cognitive.

[00:08:01] And so basically, most people are most aware of visual needs. So basically, things that fall under is the user colorblind or do they have limited or no sight at all. So basically, these types of users, they use a specific technology that for a colorblind user, this is mainly, you know, making sure that we're not just using color as an indicator.

[00:08:29] We have to go beyond that and actually use text or iconography to kind of indicate the intent of the color. And then there's for limited sight or user with no sight, they would basically be using either screen magnification or a screen reader or a combination of them both.

[00:08:57] So basically, for a magnifier user, basically it is exactly what it sounds like. It magnifies the screen. And so putting, preventing Zoom in the browser, you know, yes, it makes it so when you're on iOS and you have a really small form field, it's not going to blow that form field up.

[00:09:20] But it also means that you're breaking magnification for all users and you create an accessibility issue. Mobility, on the other hand, is things like you want to make sure that for a user who's using keyboard nav, like if there's a scroll region, you want to make sure that they can access that.

[00:09:41] Like if you can't just be like, oh, you know, you've added overflow, scroll on something and count on that to do all the work. You have to go beyond that. And then finally, like it also encompasses things like motor control. So making sure that if you're using like an icon as a button, it's big enough for the users to actually activate. Okay. I want to go back to keyboard navigation really quick.

[00:10:10] Uh-huh. How do you know which element should be keyboard, should be able to be navigated to by keyboard? Like, I think there's some obvious ones, which is like interactive elements like a button or a form element, right? Those are, those are things that, you know, is obvious. But, but then there's other times where, you know, there's other elements that you might want a user to be able to get to.

[00:10:40] What's the general best practice around that? Generally, the only thing that should be in the tab index order are interactive elements. Okay. So, there's certain use cases where you may actually make a non-interactive element focusable. But that's usually you do it for just that use case and it's not always focusable.

[00:11:08] So, for example, let's say you have like a view more button. When you hit the view more button, you know, it expands content and so that way you can see it all. Well, generally, in that case, you want to put focus back on that content. So, that way a user who is either using a screen reader or also for keyboard nav, they know what's changed.

[00:11:34] And so, basically, like you, for that instance, you will apply focus to it. But as soon as it loses focus, it shouldn't have a tab index of negative one or zero on it. I think. And you have mentioned magnification and using your Zoom keys. Yeah.

[00:11:55] When you Zoom, when you use the Zoom function and you're on a form, you expect the layout to relatively stay the same, but either enlarge but not broken. Not broken as in how it looks, but the text becomes bigger, right? Okay. I'm just making sure. I'm just making sure. I'm making sure you're on the right side of the screen.

[00:12:20] So, if for any reason, you know, a user can't access something because they're in a magnified view, that basically is not accessible. Like if they can not reach at the bottom of the screen and not reach that content, you basically create accessibility violation. Awesome. Awesome.

[00:12:40] So, let's move to auditory where, you know, if you're listening to a podcast on Spotify that doesn't have video, how could you make that sort of media accessible to? By providing a transcript.

[00:13:01] So, basically, like anytime that you have anything that has some sort of auditory function to it, you want to have some sort of equivalent in a visual form. So, if you're displaying a video on the internet, you want to make sure that there's either a transcript or there's captions at the bottom.

[00:13:22] So, that way, a user who is either hard of hearing or has no hearing can also access the content. But then also remember like something like a notification. Like if you have some sort of audio notification, but there's no like visual element to it, you need to actually provide some sort of visual element.

[00:13:45] So, let's say there was a person that was moderately visually impaired and they lost their hearing, right? And oftentimes on YouTube videos, they have those closed captioning things. Which is good if you're able to read it, but is it generally a thing where you can make those letters or those words, those captions bigger?

[00:14:14] Or how would that work? So, that's where it would most likely fall under two things. Generally on YouTube or videos anymore, you have a choice when it has the captions, but the size of the caption. Oh, nice. So, that way, one, you know, it kind of helps you, but that still may not be large enough.

[00:14:38] And so, something like a screen magnifier will come in where you can then use screen magnification on top of the increased text size to be able to read the content. And people that are both severely visually impaired and loss of hearing, like there's only so much you can do at that point, right? So, there are actual Braille keyboards.

[00:15:06] So, where basically underneath your keyboard, a Braille display will be. So, basically the user can potentially use Braille to get the information. And so, you know, even for, or hopefully between either using different types of assistive technology, the user can access the information. Interesting.

[00:15:33] But how would they read the screen? Do they have Braille screens as well? Or do they have like a Braille display? So, basically, as you're going over content, the words will change on the Braille display. That's pretty neat. All right. Shall we move on to cognitive? Yep. So, cognitive is really not thought of much.

[00:15:58] So, basically, things in cognitive are if you have something like ADHD where it's hard for you to concentrate, you have to consider that the user may be overwhelmed with large blocks of text. Or if you have animations that are continuous, you know, that can make it really impossible for the user to pay attention to other things.

[00:16:24] And so, basically, you want to make sure that, you know, you take into account that if you have, you know, animations that you have media queries that if the user suppresses animations, you actually suppress animations and transitions. And then also work with your UX to make sure that, you know, content is manageable for all users.

[00:16:52] The other issue is if you have, if it falls under cognitive would be short-term memory. Right. And so, even if it's a case of, you know, like a password field, you have short-term memory issues, you may not be able to remember your password, even going from, you know, having it written down to putting it into a form. And so, having something where, you know, like the user can sign in via an email link, that would solve that.

[00:17:21] So, basically, just thinking about the user experience from, or all of accessibility is basically just thinking about the user experience from a different modality of use. So, trying to take into account, hey, if this user has this, how can we make it better and easier for them to use? I see.

[00:17:44] So, for short-term memory and the password example, so something like a remember my password would be ideal, right? If they can't remember from one hour to the next or one. Right. So, basically, being able to either stay signed in, obviously, you know, we have our security concerns to think about in that situation. Yeah.

[00:18:07] And so, offering, you know, considering both the security level that you are under, along with the user's need. Interesting. Cool. What else you got for me? So, next is the actual coding examples. So, we have a native button here versus a completely custom button. So, the native one clearly works.

[00:18:36] We have an on-click handler for the fancy one. So, that one works as well. But, now let's say that the user's using keyboard now. I just hit the tab key. I hit return. And it works. But, when I go to use the tab key to navigate to the fancy one, it doesn't work.

[00:19:00] So, in this case, we have to add a tab index of zero. And now, let's try that again. Oops. And now, trying again. Now, we have it in the tab index. But, is it going to work? And, return does nothing.

[00:19:27] So, basically here, we would have to add an on-click handler. Or, sorry. Add a key up handler. Now, the reason why you want to use key up versus key down is the fact that if you use key down and the user accidentally holds down the key or maybe has mobility issues and may hold down the key a little too long.

[00:19:59] So, then they will basically be activating that function over and over again. So, it's better to use key up. So, that way, it's only when the user actually removes their finger from the key that it will be activated. Here, we have key up. And then, we have to check for both space and enter to make this work properly. So, when you hit enter, it now works.

[00:20:29] And then, space. Oops. Rolled. But, you get the idea that basically now you have to take on the browser's function of adding these event listeners for you. So, ideally, just use the native button. That means it will work for a user using keyboard nav right out of the box.

[00:20:50] Right now, this works for the fancy button works for a user using keyboard nav, but it wouldn't work for a user using a screen reader because we have no roles or indicators to indicate that it is a button. So, we would have to actually add on role equals button.

[00:21:18] And now, a user using a screen reader will now know that that's a button. What you want to do is go into ARIA Bothring Practices. And, basically, they provide you with a whole bunch of recipes when it comes to custom components to make them accessible.

[00:21:43] I had used slash heard of this thing called Axe that basically does, like, accessibility checks. Axe, how accurate are those? Like, is there any piece of technology we can use to be, like, to kind of tell us, like, hey, this is what you need to do on this website to make it accessible? Yeah. So, there's actually a number of static testers out there, Axe being one of them.

[00:22:10] There's also, I think, Google does Lighthouse and ECG does another version. But, yeah, they're a great start. So, they're going to catch most of your bugs when you run it on your development. Is it going to catch all your bugs? No. But a good majority of them, yes.

[00:22:31] So, starting out with in your development process, including any static tester as a regular tool before you do your final, like, checkouts, that's the number one thing to start with. But the other thing is, is when you, a lot of the unit test platforms, you can actually incorporate Axe there as well. And so, you can actually make it a part of your unit testing.

[00:23:00] And so, that way, things get caught in your DOM early on. And when it comes to screen readers, I know there's a few different types. There's a default one on Mac, which I don't even remember what it's called. But then there is also, I think, two other ones on Windows that you can run on Windows that behave differently as you would expect on a Windows machine. So, Mac has VoiceOver. And then Windows has a number of options.

[00:23:30] So, there's Jaws, which is the most widely used. NVIDIA is the next most widely used. But then Windows also has their own version. I want to say it's called Eyes, but something like that, where it's their own version. Most people don't use that.

[00:23:56] And then there's also TalkBack for Android. So, basically, if you're on an iOS device or a Mac, they both use VoiceOver. But in Android, it's going to use Google's version, which is TalkBack. And TalkBack's also available as an extension on Chrome. Do we know which platform is the most accessible out of the box?

[00:24:24] Like, as far as the tooling goes, right? Like, the screen reader or? Honestly, it kind of depends on the user. A lot of, or so, from what I've heard, it's basically a lot of people say Mac is most accessible out of the box without any additional. But that being said, is it the most powerful? No.

[00:24:50] Because Jaws is the most easy to use and most powerful when it comes to a screen reader. And so, basically, while Mac kind of, when it comes to, like, a tablet or a phone is most accessible, it doesn't necessarily mean that that's the case on a desktop. So, when it comes to accessibility, start learning about the different tools that are available when it comes to assistive technology and how users may use your software.

[00:25:19] And try to take that into account as you're building. And then the next thing is, is start getting comfortable with not only using something like Axe or some sort of static tester, but start trying out different things when it comes to, you know, assistive technology. You know, try a magnifier just for a little bit. Kind of get a feel of what your website or application will be under magnification. Does it work as well?

[00:25:45] But just try to pick up different assistive technology tools to interact with your software a little bit differently and see if it functions as well as you would like it to be. That's it. Okay. See you next time. Yeah. Yeah.