Accessibility Problems Solution

[00:00:00]
>> Welcome back from exercise two. So I got some good feedback during the break, though, kind of wanted to share a couple of things. First of all folks being a little overwhelmed by the voice over or the screen reader utility, which I completely understand it's system level. So if you start doing something like changing tabs or opening a new app, it just reads and reads and reads at a very fast pace.

[00:00:22]
One thing to keep in mind for the Mac voiceover users that command f5 will toggle voiceover on and off. So if you need it off really quick, you can do that. You can also where the gray boxes reading the text, you can at any time, just click the X in the top left, and that'll also turn voiceover off.

[00:00:41]
Another question about wanting to use voiceover with just the visual and not the audio. I'm not sure if there's a setting for it. But one thing that I often do since the visual is enough for me to test is I just turn the sound off on my Mac.

[00:00:53]
So I'm not listening to it, and then just use the text to test things. There are also settings where you can change the voice and you can slow it down or speed it up. So if you're doing heavy testing with it and you're new to it. I would really recommend slowing the voice down because it feels very overwhelming having someone talk at you very quickly while you're trying to do stuff.

[00:01:11]
Cool, so for this exercise, I think the way that I would normally just start it is by turning on my screen reader just to kind of get a feel for what the site is like. So, I'll use Command F5 to turn the screen reader on, I use voiceover here.

[00:01:24]
And then I'll just kind of start tabbing through a little bit, see what the interactive elements are. So, I can kind of tap through and I see, okay, we've got a link to this repo. Then we've got some of these dangerous form fields again, like we had before they just say Edit Text blank on them, Edit Text blank.

[00:01:41]
And then it just sort of moves on, so not super useful for screenreader users right now. So kind of with that information, I'll hop over into the HTML. So I'm gonna move over into my text editor. And I'm just gonna close this and open two dot HTML here in the exercises folder.

[00:02:00]
So that's exercises 2 dot html. And basically I just wanted to kind of show the experience of the stuff that we had looked at before. So this sort of anti pattern of using non labels to label your form fields. This anti pattern of using divs for buttons because they won't be focused by the keyboard.

[00:02:18]
And this anti pattern of using an image with no alt text so the screen reader doesn't know what to do with it. So yeah, for this one, you can kind of do either the explicit or the implicit labels that I showed before. So I like the implicit where you just kind of wrap the input in it.

[00:02:35]
So I'll do like this and move it over, and then provide a closing label tag. And I'll do the same thing for this one. So label move this over and then a closing label tag here. For the class of button, I will just get rid of this. Use a button if possible.

[00:02:56]
And remember if you need to, you can feel totally free to style buttons like you do not need to keep them gray with their border or anything like that. So you could easily do like a button with a class of like my custom button, anything you want here.

[00:03:09]
And you can reset all of those things border zero, background inherit or whatever you can do all that stuff. That's no problem at all but the button is, what's gonna get you the focus and the key down and the tab index, all those kinds of things. And then for this alt text here, go ahead and add kitten.

[00:03:30]
I'll go ahead and save that. Come back and refresh here. And then just kind of F5 again to start screen reader. And then just make sure that I got these things kind of correct or I've got everything that I can just mess with here. The question is like for the link, would that be a good place to use an aria label?

[00:03:48]
And it's really interesting. So, you've kind of have like two different ways that screen reader users will interact with your site. One way is that they'll just load up the screen reader and let it just read the whole web page, right. And so when they're reading the web page, they'll get the same context that we'll get like download the code for this repo.

[00:04:06]
But as you mentioned, which I think is great, like these links will often do that, right? A link will text off and be click here, and no context at all to it. So, if you're tabbing through or if you use that rotor that I showed earlier to view all links on the site, it's not super useful, right?

[00:04:23]
It'll be like, click here, click here, click here. Those are the three links on the page. So yeah, I do think that if you wanted to go the extra mile, it would be great to add labels to those links. Just say aria label, I mean I'll even do it now.

[00:04:36]
So we've got this here and then we could just add an aria label and we could do I guess it is a link. So it would be, GitHub page for repository or something like that. Just so that it's got more context to it than what the link is.

[00:04:56]
Another tool that we'll learn about in another section is. Instead of labelling and describing, aria also offers an API for describing which is more like supplementary content. So it's, hey, this thing is a button but what it does is it takes you to this. So it might be a good example for describe as well.

[00:05:15]
But I think that's a really good point that, we talked about images and form fields. But even links like if the context isn't there, I think that's a great opportunity to label them for sure. So if you use a div with a role of button and you do all the things, does it have a negative impact?

[00:05:32]
I would say no, but with a caveat that you have to make sure you do all the things right. So, it's like the roll the tab index the mouse down, and the key down sniffing for enter and space. Make sure you do all of those things, and then it'll perform the same way.

[00:05:47]
So, that's the cool thing is like Aria, which we're going to get into the next section. It really does let you control things with the roles and with the labels and things like that it really can alter the screen of your experience. So yeah, you can definitely do it as long as you're committed to making sure that you cover 100% of the functionality.

[00:06:05]
Because sometimes things will have just sneaky functionality, like I didn't know about enter on buttons for a really long time. I just like to click on. So things like that can be missed, but no as long as you commit to it, I think that's totally fine. So these days is it better to use the nav tag with anchors versus the old school style of using an unordered list with our eyes.

[00:06:25]
Great question nav did you know the nav does provide some semantic meaning for sure. The important thing for sure is that the things themselves are always wrapped in anchors like anything that takes you to a new page is an anchor. That's like the vital thing. I think for these tags that provide semantic meaning, but don't provide functionality like nav, for example, I don't think it's important.

[00:06:52]
I think it's fine to use an unordered list but I would lean towards using these tags. They have a lot of benefits in just like search engines in general structure the page and things like that. So I would prefer to use a nav. But I think the only important thing, I see a lot of confusion between buttons and links.

[00:07:12]
So if you had buttons that took you to different pages, that would be bad because buttons are supposed to be interactivity on a page. So as long as their anchor tags I think it's fine either way, but yeah, it's a great question. Are there differences between what we're doing today, which is just vanilla HTML, versus how would you do this with a framework React or Angular or Vue?

[00:07:32]
So for all intents and purposes, right? All of these things are supported through the frameworks in the exact same way. Although we sort of know from other things when we're using a framework that uses JSX as an example React. They don't support the data properties in the same way.

[00:07:50]
So I would have to look it up, but I would assume some of the aria tags might be camel cased instead of dashed. Similarly, a lot of other properties are. A lot of the dashes get turned into camel case things in JSX. So you might you would have to look up specifically does Aria dash label work or would it be Aria label all one word with a capital L.

[00:08:10]
But as far as support goes, they'll be the same they'll be the exact same in the sense that you'll just apply them directly to the element that. Even if it's a virtual DOM element, but for sure if it's JSX, then there might be syntax difference. And so yeah, so we talked about anchors being page to page, buttons being something on the page, but what about examples?

[00:08:29]
If you have a form and you have a submit button, but when you submit the button, you get redirected. Is there any way to tell the user hey, you're going to get taken somewhere else? So there absolutely is. Within Aria, there are roles that you can add to things.

[00:08:44]
And you got a bunch of cool roles like has transition or has pop up or has navigation. These different things where you can let the user know, hey, It's a button. It's what you think is a submit button. But we're gonna do something here or similarly, hey, it's a button.

[00:08:59]
The label of the button is register for an account, but it has Aria has pop up. So also know that when you click the button, you'll be taken to a new modal. So that's a great question. I'll cover in the next section. But yeah, Aria has these abilities to let users know what the role is or what experience is going to happen.

[00:09:16]
So yeah, awesome question.