Okay, so that's part of the specs here. So when you are in doubt of something always come back to the WCAG documentation and all the documentation around an attribute to really understand how it behaves. And it also behaves differently from browser to browser. Okay? So moving on to the next challenge, the input information. So in this case, we have a little input, let me close the code and there you go. We have an input with a lot of information. Like we have the label, we have the description, we have the error message in case it's not valid and if it's valid, well, it gets cleared on blur. It shows the error and you can reset. So all of these kind of works visually. But once again, if we are dealing with assistive technologies like screen readers, we need to take into consideration how it behaves then. And the best way to understand this is by showing you again. So let's go here. Let's turn on screen reader. Please do not use the chat. To enable screen readers. Less than, not have, less than. Less than, not type HTML public, okay. I'm, not type HTML. Sorry about that. I need to close something here. Sometimes the voice over reacts weirdly when I'm toggling between windows that involve codes. Give me a sec. Let's try again. To enable screen readers. Wait. Add accessibility. There you go. Now it's all fine. So let's jump to the input information. Add accessibility. Okay. Now tap to the input. Edit text, blank. That's all. That's all it says. Edit text, blank. It doesn't say nothing about the label, nothing about the description, if I type something, and then I tab outside. It doesn't announce anything about being invalid. So how can we make this work? There is multiple things that we need to take into consideration here when we do, when you create an input. One of them is the label. So in the code, you can see that the label is not connected to the input, and that's something that's very very important. So there are multiple ways to do that. And one of them is HTML for, HTML, now, I'm having a blank, it's HTML for? Yeah, it's like HTML for where you pass the ID like email, then you provide the ID on the input, email. With this, you are connecting the label to the input, then you need to connect the description to the input. And the way to do that is using ARIA described by. So with ARIA described by, you pass an ID. And in this case, the ID can be email hint, and you pass the ID inside and it's connected. We can start with just that. Even before opening the screen reader, I want to tell you, or I want to show you how you can make sure that these things are semantically connected without using a screen reader. And the way to show you that, I need to talk about the accessibility tree. So we have the DOM, right, as you know. And then, we also have the accessibility tree, which is a version of the DOM, but meant for accessibility. The way it works in the DevOps tools, let me jump here, is like you go, you open the DevOps tools, and in the bottom, we have this accessibility tab. And when you open the accessibility tab, it shows you the accessibility tree, so, the accessible version of the DOM. And, for example, if you click on, for example, this heading, error handling, here, it tells you, look, this accessibility element has the name, error handling with the content, the role is Heading Level Two. Basically, every element that you create in the DOM is an accessibility tree version. Okay? So, for example, if we have a button, this one, GetLottery, it tells us, look, this is a button, and it says, look, the name is GetLottery, the role, button, and it's a focusable element. If we, for example, go to this like button, here, even the like without the like, just the icon, like, you have the button here, and it tells you, look, it has the name, oops, I have a bug here. I have a bug, let me quickly fix the bug, what's wrong here? Okay, toggle buttons, aria-label, like. There you go, there was a bug here, I'm sorry, okay. Let's forget that, let's pretend it didn't happen. There you go, button, aria-label, like, and it says, look, it has the name, like, and it comes from the aria-label. The role is button, it's focusable, true. And when you click on it, where is it? Oh, I know, okay, I have the aria-label and it's missing the aria-pressed. That was the bug, but no, is active, B. There you go, you have now the aria-label, aria-pressed, and it also tells you when it's pressed or not. Pressed, true, click on it, pressed, false. These type of things, it's very useful. These accessible tree, it's very useful for you to make sure that, okay, I've done my job when it comes to accessibility. Then it's up to the screen reader to read this and translate that into whatever they translate. So Voice Over does one thing, NVDA does another thing, and depending from screen reader to screen reader, they will interpret this, these accessible tree and create their own announcements, okay? So, a way for you to better understand what is accessible tree, I have here a slide for you. So let me go here at the bottom. So the way it works is, you have the HTML, right? The HTML creates a DOM tree, and this DOM tree, you have the UI, right? And you can manipulate this DOM tree with JavaScript, right? But the browser also takes this DOM tree and transforms it into the accessible tree. So when you are using a screen reader, the screen reader is reading the accessibility tree at the end. So your work is to make sure that the DOM is correct, the browser will create the accessibility tree, and it will be read by the screen reader or any type of assistive technology. And the thing is, if you think about it, there is official specs for HTML. There are official specs for JavaScript, CSS, but there is no official specs for the accessibility tree. So, for example, when you have like, are you pressed, true or false? Like you have it here, but screen reader might announce it like selectable or not selectable. The screen reader, voiceover. But another type of screen reader might announce it slightly different. So it really does not depend on us to control our screen reader announces something. So the best we can do for now is making sure that we have the correct attributes so that the accessible tree here is properly done, then it's up to the screen reader to announce it as it should announce, okay? With these in mind, we can go back to our little input. So we have our little input and it says, look, the name is empty, we do not have any name here. So, because it's missing your email. So let's fix that. That's D3, mmm. And we have the input, ID, email, HTML for email, and then the label that was the part that I was missing. So label here. And then if you go to the input, it tells you, okay, the label of this input or the name of this input is your email. And it comes from the label through the attribute label.
Comments