00:00 Accessibility is a very, very big subject and it's very, very important in your applications for various reasons. So for one, the people who are already at a disadvantage don't need you making an inaccessible app to make their lives that much more challenging.

00:17 So please, just like accessibility is about caring about people, especially those who are already living life in a disadvantage situation. It also makes it better for everybody. So you may have two functioning hands right now, but maybe you break your arm and now you have to type with one hand.

00:35 It would be nice, even if you temporarily are disabled, that you're able to continue to use the technology you're using. In addition, even if you're completely, fully abled, having a more accessible app makes it easier for people to use in general,

00:53 especially power users who like to tab through the UI and stuff like that. So we care about that. And then also you can get sued. If you fall under Section 508, then you can absolutely get sued, and people do.

01:05 It's not great. So yeah, if that's what gets you to actually care about accessibility, then so be it. But it is a much bigger subject than we will cover today. So there are things like screen readers we will talk about, focus management we'll talk about,

01:22 color contrast is another thing. And we've got tools for helping us with the color contrast. As I hover over all these different things, you'll see right above where my cursor is, there's that accessibility line there. It gives me the name and the role, and then whether it's keyboard accessible.

01:38 But also in some instances, when we have a color, let's see if I can get a color right here, it will also tell us whether or not that color contrast is high enough. And so you can use these tools to help determine our color contrast.

01:54 But yeah, we won't be getting into that today. Another important subject, though. Keyboard navigation, also very important. That's related to focus management, but making it so that you can navigate around with your keyboard. ARIA, we actually have this. Oh, I forgot to mention WebAIM, Web Accessibility in Mind.

02:13 So like I said, it's a bigger subject than we have, but if you want to really dive deep, there's a lot of good content in there. And then we have the WCAG, that's the Web Content Accessibility Guidelines. Lots of really good content in here for reference that I recommend giving a look at.

02:32 So then we have the ARIA Accessible Rich Internet Applications, the Why ARIA specification. It is in-depth. There is a lot here.

02:44 But yeah, so lots of, these are our accessible roles. Most of these, or many of these are actually implicit. So as we saw over here, we had a role right here of text box for this input. And that is one of the implicit roles.

03:01 But there are sometimes when you're building special components that need to have explicit roles like alert and banner and stuff like that. And then we have animations. Sometimes users want to be able to control whether or not they see animations at all. So you've got to consider that, and we're not going to cover that today.

03:16 Also, even the way that you word things has accessibility implications, and even the languages that you support also. Another thing that we won't be covering today, but another important thing. There is a lot to do with accessibility. It is not an easy task, but it is a very important one, and I recommend that you invest time in making it happen.

03:35 So let's talk about form accessibility. That's where we're going to focus today. So this is not accessible, and this is. So our label is associated to our input, and the way that you do that in React is using the HTML4 attribute.

03:50 And this, some people may not know, but we also have the class name attribute, and some people wonder, why is it just not class? Part of it is because class is a reserved word in JavaScript, and so is for. That's for for loops.

04:10 But this is a brand new language. They could have made that work, and they totally could have. I'm glad that they didn't. What they opted to do was, instead of using attributes, they are talking about properties. These are props, and the property for the for attribute on an element.

04:27 So here we've got this one right here. We've got the for attribute. If you look at the console, and we say $0, that's referencing our label. If I say $0.4, that's form. Four does not exist. That's not a thing.

04:46 You can say get attribute for, and boom, now I get the attribute. But to get the property, you actually do HTML4. Fancy that. We have a class on here. If I do class, that's undefined. Class name? Aha! There you go. Now that's interesting.

05:05 So React actually went with the property name, not the attribute name. That's why it's HTML4 instead of for, and why it's class name instead of class. I really prefer this. I'm glad that they went with that. But just a little bit of React trivia for you.

05:22 Continuing, if we wanted to associate error messages with our inputs, which we do for accessibility reasons, then we add this aria-invalid to signify to screen readers and other technologies that this field is invalid.

05:39 And then use aria-describedby with a value that points to the ID of another element. And screen readers will use this to inform the user of exactly what is wrong with our field. Unfortunately, we are using aria-describedby instead of aria-error-message

05:58 because screen readers have varying levels of support for that particular prop or attribute, and it's not good enough. So we have to use describedby, which is a real shame, to be honest, but it is what it is. IDs must be unique. So we're using an ID right here and an ID right here.

06:17 Those have to be unique on the page. In our case, for our little app, we actually only render one of these on the page, so it really doesn't matter that much. But often you do have multiple entries or similar forms on the same page at the same time.

06:32 And so to create a completely unique one, you can use useIDfromReact. And with that, it generates just this random ID, and we have a piece of an exercise that actually does that. Finally, I just want to say that there are a lot of different types of components.

06:49 We saw all these roles. There's combobox and checkbox. And there's date pickers and dialogues and just so many things that you can build that are part of the ARIA specification. I have built some of these things, and they are not trivial.

07:08 They do take a fair bit of effort. And so while you can build it yourself, there are lots of great libraries for us to be able to just include them. And they are perfectly accessible and awesome. So I recommend using libraries.

07:25 We're using Radix in the Epic stack and in what we're doing today, but there's also React ARIA is another good one, and Reach UI is another good one. And so you just want to focus on libraries that actually take these things into account. That way you don't have to worry about finding all the bugs when your users complain.

07:42 With that, I think I've given you enough. So let's get going on this accessibility exercise of the workshop. And I think that this is really important knowledge for you to have. So enjoy.