Loading
Current section: Accessibility 5 exercises
solution

Improving Accessibility and Form Associations

Transcript

00:00 So let's open up the editor here, and we'll come over to our reset button. Now, I actually already kind of did this for you with the status button. Let's explain why the reset button isn't working. So we should be able to type in there, hit reset, and it should reset. The problem is, with the way that the design is formatted,

00:19 especially useful for these things that scroll a lot, we have this as a detached section of our scrollable content. So it's outside of the form. You'll see we've got that div, and here's our form. These are siblings. And so when a button, or an input field, or any other form element,

00:36 is outside of the form, you need to associate that element to the form that it's supposed to be associated to. So I did this for you because I wanted to make sure that in that first exercise, we had the submit button actually working, but I didn't do that for the reset button.

00:54 So we are associating this status button. So when we hit submit, that status button, we're associating that to the form using this form prop and passing the form ID. That form ID is the ID of the form. There you go. It's magic. And it's just globally unique on the page.

01:12 We never have a situation where we're rendering two of these, and so we're good with just hard coding that. So we have to do the same thing for our reset button to get the reset button to work. So it's actually pretty simple. We'll just copy that and paste that right there, and we're done.

01:28 So now if I make some sort of change and we hit reset, that resets for us. So now we're associating these things. And a lot of form accessibility has to do with just associating things properly. So our labels are going to be the same sort of thing. Here, we're going to add an ID to the input.

01:47 So we can say ID is our title input, and then we can have the HTML4 title input. And yeah, that's that. Here, we'll leave that right there. We'll talk about that as well in a second. So now I can test this by clicking on title, and it focuses on the input.

02:07 So I know that that association has been made. And if I turn on voiceover again, and we navigate here, it says title first. So it's telling me the name of the input. So I, as an assistive technology user,

02:25 will know exactly where I'm trying to go as I'm navigating around. So let's do the same thing for our content. We'll have an HTML4. This is our content input, and then we'll have our ID content input.

02:42 So there we go. I click on this, and now I'm focusing on the content. So we know those are associated. That's good. You can also, I recommend, look at that input, and then there's this accessibility tab right here. It might be under these three dots. I dragged that over because I use this quite often.

03:00 And here, you can look at the accessibility tree. It's awesome, and it will show you some computed properties. So from the label, we get the name of title for this input. This has implications for testing that we'll talk about at a future workshop. You can find all the other implied attributes.

03:18 Here, we've got the role is implied as a text box, so on and so forth. So pretty useful information inside of that accessibility tab, just to kind of make sure that your accessibility tree is what you want it to be. All right, let's just do this last thing, and that's the extra credit. Using React's use ID hook.

03:36 So you might think that we could just say title ID is math.random, right? That should work. It really doesn't matter what the value of the ID is, so long as it is unique. So let's go with that. Sure, why not? TypeScript doesn't like that because it needs to be a string,

03:55 so we'll say toString. Great, so with that now, we take a look at this input, and let's give ourselves a little bit more room. We have our ID. There we go. That still works. Like, there's no problem with this. We turn on voiceover, and it's still going to be able to identify this as the title. So no problem there.

04:14 But we do have another problem, and that is our hydration is going to be a problem. So here, HTML4 did not match. On the server, it was this. On the client, it was this, and of course, that makes sense because it's going to server render some random thing, and then it'll hydrate with some other random thing.

04:31 And so that's why we use React's use ID hook, which will keep it consistent both on the server render as well as on the client render. So I can refresh, and I get the same thing, both server and client. The way that ends up looking is this really funky-looking ID. I don't really care. It doesn't actually matter.

04:51 It just needs to be the same between the two. So if you want to, you can do that here. I'm not super concerned because we're not rendering two of these note edits on the same page at the same time, so we can have a unique input here. But if you were to maybe make an abstraction around making forms

05:09 and generate IDs, that would probably be a good thing too, and we're going to do that in the future. So in review, all that we did here was first, we associated our reset button with the form by passing the form prop. You can do the same thing if you have an input that you want to have somewhere else.

05:24 You can say form is form ID, and now this input will be associated to that form. And when that form is submitted, that input value will get submitted as well. So the form prop, pretty useful. That's all like regular HTML stuff. Nothing about Remix or React or anything in there.

05:42 And then we did something similar for our labels. We said the input now has an ID, and then we associated the label using HTML4 to that input by its ID. And that takes care of some accessibility problems for us, and so our users will be a lot happier.

06:01 Not even necessarily just those who are using assistive technologies, but also just all the users in general have a nicer user experience when we care about this sort of thing.