Web Accessibility in JavaScript Apps

Hi, everyone. Welcome to this workshop. I don't know where you are from, but I expect you to be from anywhere in the world. So today we'll talk about web accessibility in specific in JavaScript apps. The workshop, the entire workshop will be on code sandbox. You can clone it or you can clone the repo or you can follow along directly on code sandbox, and it will be full of practical examples around accessibility in a React app.

We'll start with routing, links and buttons. We'll go through toggle interfaces like more buttons and menus and stuff that collapse. And then we'll do some error handling like loading states, inputs, when you type something and there's something wrong or you can't handle it and last but not least, if we have some extra time we'll go through some custom interfaces, generated data and animations. All of this in three hours. Let's see if we have the time for everything.

And I would like to start with a theoretical presentation about accessibility but at the same time I really want to go into code. So let's start with a little bit of code and then we'll go to the theoretical part and then get back, let's get back to the code. So the first one, routing. To make it easier I will open the project directly on a new window so in Codescenebox you can click this icon here, open a new window and it should open a new window, wait a few seconds and there you go. So the first one is like you have three links here right and if you click on them it goes to a page, right? Goes to the page, you click again and this one opens a model.

Thing is, okay it looks right, right? What about keyboard? If we use keyboard and you click tab it looks right as well, you click tab, you click tab and it works fine. But there are more ways to open links. For example, let's imagine that I can I want to open this link in a new tab, so I do right click and there is no way for me to open the link. Let's try the second one. Oh, open a link in a new tab and the third one, open a link in a new tab. What happens is if I click here to open this module in a new tab, open link. new tab there is no module here. So let's see a little bit about under the hood, all of these links are created. So if we inspect it on here, we can see that all of those look like links. But not all of them are exactly the same. The first one is a button. The second one is actually a link with the href and the third one is a link with the href. So the thing that I want to tell you here is not all links should look like links, or not all links should be, in other words, not all clickable elements should be anchored or buttons. It depends on the function that you want to create here.

So if the link goes to a different page, make sure that the link is really a link, not a button. Because the first one is a button. If you right-click on it, you can see that you cannot open the link in a new page because it's not really a link. If you go to the code, let me show you the code, the code is a button with a onclick that goes to the page. Second one is really a link, and the third one is a onclick as well. The point here is, if you really want to go to a new page, use always the link element, the anchor element or the link component from React Router. In that case, when you double click on it, it opens a link in a new tab. And you can click on it. Let me do it here, this one, in this case. So, open the link in a new tab, and it opens in a new tab. Does it make sense for you? How many broken links that you have implemented out there? Using a button or even worse, using a div, where you do a div, div, div. One click. The div is even worse, because with a div, you cannot even interact with a keyboard. Like if I use a keyboard, the tab key, it goes directly to this one, it jumps the first one, because it's not a link, it's a div. So make sure to be always a link, and if you are navigating between pages, to make it a real link as an anchor, not a button.

Another thing that I would like to talk about in the second scenario, where clicks that look like buttons is, it's very common for me to see in react apps, especially when you included in React. The link component from React Router. And you have a link, but you want it to look like a button, so you have a button inside the link, a button component inside the link component. And although it works, the thing is, in the markdown, you have literally a link and a button inside, which makes something like, if I tab, let me tab here. It tabs the outside link, then I click tab again, and it tabs the inside button, and then it goes to the next one. So you are creating a clickable link inside a link. And that doesn't make any sense. Actually, that's considered invalid HTML. So in those cases, what you want to do is, like, really have a link component and style it as a button. In this case, we are using style components. Style link, and then you have the CSS to make the link look like a button. So in this case, the DOM is correct. So let me open this again. So I started with A. In the first one, you have A with a link, and then the button inside – this is wrong. Don't do this. And the second one is the correct one, where you have an anchor with the link, you know, any button, but it looks like a button. Does this make sense? Yeah? Take that into consideration when you deal with links.

Last but not least, when you are dealing with a model, for example, like this one, if the model doesn't go anywhere, it should be a button. So in this case, Get Started, see, you click it's a model – it's a button. It's not a link. It does not need to be a link. Okay? That's all I have to say here about routing. Make sure that anything that you do in your apps, you are using links for navigation and buttons for things where you do not change between pages. There is this article called buttons versus links from CSS tricks, which is an extended way. It's not this one. Whoops. Buttons versus links, CSS tricks. Not this one. The link is incorrect. Complete guide. This is the one. This article is like a complete guide to links and buttons, and it explains all the differences between anchors and buttons and when to use one or another. Take it into account the next time you are deciding between one or another. Okay? Also, when you are dealing with single page applications, you might consider some other things related with routing, and Gatsby wrote this article with some findings about what things you need to take into consideration, and one of them was using the proper link but not components.

Now, all of the exercises will be a little bit more or less like this. We have a challenge. We go through the problems of the challenges. We fix the HTML, and then we move on to the next challenge. The way this repo is organized, you have every exercise or every demo in the original folder, so you can illegitimately switch between the different things and start a new one. And we'll go through each one of the sections. But if you want, you can also check the solutions later on with, you know, the solutions for each case.

Now, before we jump into the second section, togglable interfaces, I want to tell you a little bit more about the behind the scenes on accessibility. So let me open the presentation here for you. By the way, I didn't introduce myself in the beginning.

I'm Sandrina. I'm from Portugal. And I'm a front end engineer who helps to turn ideas into accessible experience. A fair description, right? So at the moment I'm a team leader at remote and one of the things I love most about remote is that it gives me the flexibility to talk about accessibility during my working hours. And so that's what we're doing here. Let's talk about accessibility.

So, accessibility, the irony of accessibility, the word itself. It's a word that it's hard to say and it's hard to write. So it's very common for you to see A11Y, which is A plus 11 characters plus Y. So, A11y. And let's start with some myths around accessibility. So could you tell me on the chat, Discord or Zoom, what is for you the biggest accessibility myth? Anything. Someone wants to shout something. It's hard to test. Only a few people need it. Accessibility just putting alt on images. I like that one. Users do not scroll. It's for them. Oh, I like this one. It's for them. So few users need it that we shouldn't work on it. Accessibility is just about color contrast. We deal with it at the end. This could be accessibility guidelines. Say it wrong. I could take a screenshot of all of this. But I really like one of the myths which is it's for them. So accessibility myth number one. Accessibility is only for blind people. And I'm going to tell you. Yes, accessibility helps a lot. It makes a lot of difference for blind people. But it is not only for them. If you make it right for blind people, you can help many, many other people at the same time. Accessibility helps a lot of people. Let me tell you. Let me show you how. For example, when it comes to visual impairments, it's not only blind people. It also helps people with colorblind or low vision. Or nowadays, everyone likes the dark theme. It's not exactly because we have some disability, but we prefer it depending on something else. From a hearing perspective, it helps people who are deaf or have some hard-off hearing, but also there are a lot of people who use subtitles, for example, captions in this case, and they don't have any hearing impairment. For example, I love to use captions because it helps me to understand a new language. It also helps people from a motor perspective. For example, not only if you lose a limb or you have some paralyzes, but also imagine that you are in the bus, and you are struggling to click that tiny button to close the modal. So it helps on that moment as well. Last but not least, for example, cognitive. We have the same information on the screen in three different ways, and all of them, you can quickly say that the red is the biggest because of the graph. So it also helps with understanding some content, okay. And so when we fix accessibility, fix accessibility, we are taking care of many, many people at the same time. So accessibility is not only for them, it's for everyone. Another myth about accessibility is like, oh, they are a tiny minority, and I would like to tell you that they are around 1 billion people worldwide. Like 1 billion of people have some sort of disability. If you compare it, the population of Europe is just 0.75 million, so it's like if you exclude people with disabilities, you are excluding the entire Europe. So it's not the minority, it's a lot of people, okay. But for me, the biggest myth is that disability is a health problem, and I would like to tell you that disability is not a health problem. There is a spectrum from disabilities that are permanent, temporary, or just a situation. For example, yeah, if you are blind, or if you lost one arm, yeah, you have a permanent disability. But in many situations in your day to day, you might have some type of disability, and you'll benefit from accessible websites. So this personal spectrum, which is the Microsoft inclusive design team, they also say, not they, but the World Health Organization, they say that the disability is dependent on the context. In other words, disability basically is an interaction between you, your body and whatever that is around you. So it's interaction between features of a person's body and features of the society in which he or she lives. So a disability is not about the person, it's about the context where you are, and you only have a disability if the environment around you is not supportive of your abilities. Okay? So with that in mind, yes, you can solve accessibility for one, but by doing it, you're for sure improving it for many others. Okay? So now the next question is how to make the web accessible. There is this thing called UCOG, Web Content Accessibility Guidelines. And in case you don't know, it's this webpage with all the guidelines that dictate if a website is accessible or not. And the irony is that this webpage is not very accessible, right? It's like it's scary. It's super, super long with a lot of text and you don't know where to start. So I want to introduce you to UCOG from a different perspective. So when I think about UCOG, I think about layers. So UCOG is split into four principles and each principle has their own guidelines and then each one of the guidelines have success criterias. So let's start with the four principles. The four principles also known as POUR are perceivable so that people can be aware of the content. For example, that images and the old captioning. For example, the second principle is operable, which is like people can navigate and find the content. For example, the first exercise where we saw the buttons, make sure that the buttons can be accessed by keyboard and that they can work properly if they are, for example, a link. The third principle is understandable. That the content is readable and appears in a predictable way. For example, if there is an error, that the error is there for everyone to access. And last but not least, robust. Making sure that assistive technologies like screen readers can understand the page and interact with the page properly. For example, that the button is really a button, not a leaf or that all the headings are properly set in the page. And with these four principles, perceivable, operable, understandable and robust, it's way easier for you to understand the guidelines. So, let me go here again. These four principles here, it's basically this sidebar. So you have the first principle, perceivable, operable, understandable and robust, okay? So when I'm thinking about accessibility, I make all these four questions and I try to think about, okay, what should I have into consideration when I'm thinking about perceivable and then I'll read through the guidelines and then I'll read into one of the guidelines. For example, making sure that the use of color is correct. I click on it and then I read a little bit about it and if I really want to understand more about it, I click understanding use of color or I click here and then it's a page all about understanding the use of color and if I really want to know, okay but how do I meet the use of color criteria? You click on it and then it goes to a page that shows you multiple examples of how you can meet and how you can fail this criteria, okay? That's how I look at UCARG and how I get started with it.

It's like Pokemons. You just get started one by one, each week and eventually you'll feel more comfortable around them, okay? And if you are hearing the noise on the background I'm sorry, there are some construction work on the background.

So with that said, there are some criteria that are easier to accomplish than others and that's what we call conformance levels from A to AAA. So A, AA and AAA. For example, the A is making sure that a live video has at least a description. A AA is making sure that the live video has captions. And the AAA is that same video also as a transcription at the same time. So usually the higher the conformance level the harder it is to achieve it. So usually we strive for AA. Most of the websites strive for AA. The AAA is mostly for health websites or websites from the government, but it really depends on the type of audience that you are trying to interact with.

So if you ask me what is accessibility, for me accessibility is nothing else, nothing more than caring about people. It's not about rules or guidelines, it's about people. If you care about the people around you and if you make the question, what if this person doesn't have, what if a person cannot use the mouse? What if the person struggles to see something? It's just what if. If you care about the person on your side, you'll make your website more accessible than if you look exclusively to the UCoG guidelines. So, in other words, for me, accessibility is our duty as web creators. I know we should... Probably we came to the web for fun, making good websites or funny websites, but at the end, we are the architectures. The architects of the web world, so we must make it accessible for everyone. And that's all for now. Enough talking, let's go back to code sandbox.

But does anyone has any questions around this part? Let me check the chat. No? No, okay. No, let's go back to the code sandbox.

So, the second scenario, toggleable interfaces. The second one, it's on the demo original D2. So, here we have a button, this toggle button with a like. And using the keyboard, you can click on it, right. And it's pressed or not press. Visually, you can understand its state, right. The thing is, there are people who use the web without seeing the web. And they rely on some assistive technology. For example, screen readers to understand whatever it is in your webpage. And if you use a screen reader, let me open this here in a... In the extra page, there you go. And if you use a screen reader, you don't have the visual clue that tells you, look, this is clickable or not. So all the you tell semantically that this button is active or not. So let me tell you... Let me show you first. So, in this workshop, I'll tell you a little bit about screen readers. And I will be using VoiceOver. So the way for you to use VoiceOver... Let me go here. As you go to the system preferences, accessibility menu, then VoiceOver, and you click to enable VoiceOver. And then you have the shortcut Command F5. When you turn on the VoiceOver, you can use the control option plus the arrow keys to navigate back and forth. So I'm going to do that, and you'll tell me how it sounds on your side. VoiceOver on system preferences, accessibility window. Could you hear my VoiceOver on my side? Yes. Yeah. Cameron Green to everyone. VoiceOver, yes. Okay. Cameron Green to everyone. Yeah. Okay, that's the thing, if you write on the chat at the same time I have the VoiceOver turned on, it will announce whatever it's on, the chat. So while I'm using it, please do not use the chat. Okay. So let's try that again. Enable VoiceOver. VoiceOver on system preferences, accessibility. Okay, there you go. So when you are on a webpage, there are multiple ways to use this, but the way I'll use it to make it easier, I will click somewhere in the page so that the VoiceOver starts reading from that point on. So for example, here. Okay. So now I will use the Control Option and the keys back and forward. So Control Option, right key. Again. Okay, it tells me that it's a heading because it's H3. Okay. So I will click Control Option space. Okay, I pressed. Press mic button. I'm pressing again. And visually, you can tell that it's active or not. But there is nothing on the screen reader that tells you if it's active or not. In other words, let's do this little experiment. Let me disable all the styles of this page. Now, you can imagine that this is what a blind person sees, a page without any styles. So if I click on, where is it? The like button. I'm clicking on it, and visually cannot tell if it's active or not. The same with the screen reader. Voiceover. Hold up. Mic button. Press mic button. Press mic button. See? So how can we tell a screen reader that the button is really Voiceover blocked. pressed, or active or not? So the way to do that is using ARIA. So ARIA are these little attributes that you include on your HTML, and it enaces the HTML to provide some extra information.

So the only goal, or the only job of ARIA is to provide extra accessible meaning. It does not change styles. It does not change the behavior of an element. It only tells something extra semantically. So in this case, we can use on the like button, we can use ARIA, and then it has multiple ARIA attributes, and one of them is pressed. And you can say, like, are you pressed true or false? In this case, because we are dealing with React, we can say, look, the repress matches the is active state. So if it's active, it will say, are you pressed, true, and then are you pressed, false. Let's save it. Let's go back here. Let's just double check the DOM. Are you pressed, false? And I click on it. Are you pressed, true? And let's see how that ARIA attribute changes the behavior, the announcement of screen reader. So let's turn it on again. Let's go back here. I will click on it. See, now it says select. Now I'll click again. There you go, now it's clear for the screen reader to announce if the button is selected or not. There you go. The thing is, if we go to the second button, you can only, uh, you understand, you know, sorry, you can understand the state, but semantically there is nothing here saying that, you know, that it's a like button. So let's see how the screen reader interprets that. Like toggle button. The only thing is button. There is nothing explaining what's the meaning. The meaning of this button. So there are multiple ways where you can provide the semantics of an element. And one of them is using ARIA as well. So in this case we can say, look, the name of this button is like, and the way to do that is using ARIA label. So with ARIA label, you can say like, and then the demo. Voiceover on drone, hold over the like toggle button, like button. There you go. Now it says like button and when I click on it, let me just... Let me just put here ARIA pressed as well. Is active, B. Voiceover on drum. Here again. Hey one, one top toggle button. Toggle button. There you go. You are select like toggle button, like selected toggle button. Please select like toggle button. See? Now you could improve the accessibility of both buttons. In the first one, you just provide the state of press and the second one you prove. Voiceover on. And the second one, you provide both the label, the name of the button and the state of the button. In the DOM, I can tell you here, show you here, you have button, ARIA label and ARIA pressed. Okay. This is a case where you need JavaScript to make this content accessible. That's one of other myths where JavaScript breaks accessibility. Yes, it breaks, but in some cases, it's the solution to make modern websites accessible. You need it, there is no other way around to accomplish this without ARIA. And for dynamic ARIA attributes, you need JavaScript. So, another thing that I want to tell you about ARIA is that the first rule of ARIA is do not use ARIA, which means it's like, it's not because you know ARIA, that you need to use it everywhere. For example, these ARIA label, there is other ways to provide some content to an element without using ARIA label. For example, you could say something like, you have a span here and like, and you save it on it, okay. And you have this. But you could say something like, look, it's here, but I want to do some style to make it display, yeah. What did I miss? Oops. It's missing one. There you go, something like this. And you think, oh, okay, the text is there. So it should be visually it should be, it's not there, but it's in the DOM. So the screen reader should catch it and read it. The thing is, there are multiple ways where you can hide content. And depending on the way, on how you hide the content, it can be hidden from screen readers or not. And when you use this plain none, it's really hidden from the DOM or from the screen readers. But for example, if you do opacity zero, like 0.5, so that you can see it, it's there so the screen reader will announce it. But if you put zero, it occupies space on the DOM. So there are multiple ways where you can use CSS to influence how the content is announced or not to the screen reader. And if you want to know more about it, is in this article, hiding content responsibly. And it explains all the ways that you have to hide content and how it affects the screen readers. If it's visible or not and if it's really accessible or not. So in this case, what do we want is like, we want to hide it visually, but semantically we still want it there. There is this utility, very popular utility, CSS utility called, in this case I'm gonna use a typical CSS and it's called SR only, I mean, you need to create it. But this class, which is screen readers only, it does the magic. So basically it hides the element, but it's still there for screen readers and other assistive technologies. And let me explain to you what this does. So here we have the button and inside we have the like. Little bit more of the zoom. And this SR only what it does is multiple tricks. But so you have the link here. The first thing that it does is position absolute. So it does not occupy any space in the DOM. Then it makes sure that the way the height, the bedded and margin are all zero, or the minimum content. It also has overflow within just in case. So it really does not take by any space and it uses this clip CSS attribute with a rectangle of zero pixels. So it's to really hide it from visually and just in case if the element has border, it also resets the border of element. So this little trick hides the element visually but it's still there in the DOM. So with this approach, if we use the screen reader. There you go, you have the like toggle button.

The advantage of using this, this SR only instead of audio label is that it's easier for you to handle translations. Like if you like, if your website is not translatable and someone is using your website in another language, Google translator on any other browsers can translate the DOM automatically. So they will catch this text and translate it. And with audio label, some translation tools do not catch it because it's an HTML attribute. Google translator catch that but some other translators might not catch it. Another advantage is for SEO or for some crawler in the page, it can clearly understand that the content of this button is like. I see some questions on the chat so let me do a quick pause here. Do we have a list of most useful ARIA attributes? I do not have a list of most useful but there's the entire list of ARIA attributes on MDA, yeah. Where you have all the list of all the ARIA attributes. It's like 30 something attributes at least. The most useful it really depends on your context, there is no such thing as useful, it depends. If you are dealing with this, I don't know, with a section it doesn't make sense to use ARIA pressed. It really depends from the type of element that you are trying to create. I hope that answers your question. So, the other one is without JavaScript you can only build accessible button that's meant to be clickable, only rather than having state. And without CSS we can only build accessible button that's meant to be clickable only rather than, I'm sorry, I'm not understanding like me. To be clickable only rather than. I'm not understanding the question. Sorry, Devin. Okay, I think I will skip this one. Sorry. Are you asking if I can build this button to make it accessible without JavaScript? Not really because if the button changes, let me open here again. Like if the state of the button changes, this state is only changing using a JavaScript. So you also need JavaScript to mark the Aria pressed state. There is no other way around here, as far as I know. Okay. Yeah, I was meant to ask just, yeah, if it's possible to build accessible buttons. No, in this case. Without JavaScript. Anything, you know, that's the purpose of JavaScript. Apart from simple buttons I guess. Yeah. But it's only for pressing, that's it. Yeah. Anything more complex you would need JavaScript to make it. Exactly. Exactly. If you press it and it goes to another page, there you go, it's a link. So there you don't need JavaScript, but for these types of toggle things like this, no, you need JavaScript here. Well, if it's a button that basically just submits a form and reloads the page and then, you know, your servers that render, reload the page and then you have the button in the state that is liked and then it has the correct Aria attribute, then you can also do it without JavaScript. You know, 1995 webpage for Slic3r. Yeah. In that case, when it's a submit, it's a button. It's a normal button. It's not a toggle button. So in that case, you don't even need the Aria pressed attribute. Okay. The next one, maybe you can use InputCheckBox for this case. So, not really. So there is a difference between toggle buttons as buttons, really, button elements and InputCheckBox. And the short answer is, InputCheckBox are a form input. They are meant to be used in a form where there is some type of submit. Where you, you know, change something on the checkbox. You click on it, and then you have a submit button that makes the final action. If you are doing something where the action happens immediately, that should not be InputCheckBox. There is this article. Let me look for it. Let me, give me a sec. I will try it on, on Discord, that explains the difference between buttons, toggle buttons, and InputCheckBox. I think it's this one. There you go. When to use a switch or a checkbox, and it explains that, like, if you have a form where you have like a button to submit at the end, yes, use a checkbox, but if it's not that, it should be a toggle button, which is like, you know, a toggle is the, you know, a button with aria-pressed. I will put the link on Discord that you can read it after. So there are some semantic differences between checkbox and button, okay? Okay, the next one, when do we hide text visually instead of using arial-label? Short answer, whenever possible. Whenever possible, I rather use the ASR only instead of arial-label, okay? That's my short answer. Like, if this is more inclusive, so it supports translation and all of that, and it doesn't mess with the DOM that much, I rather use this, okay? But at the end of the day, it's up to you. But I prefer this one. Okay, t-r-t-r, wait, it also says. Okay, I think that's all for now. Let me check this card, okay, let's move on here. Right? Right. Okay, next one. What time is it? 47, okay. The next one is collapsed content. In this case, so we are imagining using the keyboard. Let me go to the full screen. So I'm using the keyboard, tab, tab, all the tab. I click actions, I open, tab, tab again. Let me do some zoom here, tab. And everything works fine, right? What if I close it and then I tab again? Oops, we are lost. Tab, tab, tab. Oh, now we are here. So what's happened in the meantime, this was hidden, but for some reason, like, it was hidden visually, but it was not hidden semantically, like from the keyboard. So somewhere it was still on the DOM and accessible by assisted technologies. And yes, a keyboard is an accessible, assisted technology. So what's wrong here? Before I tell you what's wrong here, I want to tell you about a tool that I use, an extension called Accessibility Insights for Web. This extension has a lot of things about, detecting accessibility issues. And one of the things that it has is this ad-hoc tools, where you can for example, check for color, or the headings, it shows all the headings on the page. Like H1, H2, H3, et cetera, et cetera. And another thing that it does, is tab stops.

So when you click on it and you activate it, now when you tab around the page, it tells you the path, the visual path from where you are currently in the page. So I'm tabbing, and you can see that I'm in this copycat buttons that are hidden. And then it goes to the hiding content, to the reference. So I really like this tool when I'm debugging websites and I want to better understand where the tab goes, where the focus goes. So let me just, you know, oops. Disable it. There you go, again. So we can understand that this copycat edit buttons are not really hidden. So let's understand what's happening here.

Actions. We have this button, right? And then we have a nav with the list inside. Can you give us a link for the tool? Sorry. Accessible. The link is on the Readme. If you go to the Readme developer extensions is the first one. Accessibility insights for the web. Okay? Let's continue here. So we have the button, and then we can see that the nav has some fancy animations here. So when it's closed it has this clip path, and the clip path extends when it opens. I don't know if everyone is familiar with clip path. Actually, that's something that I really love about Firefox, is that it's really nice to understand how clip path works. So to make sure that everyone is on the same page. I know this is about JavaScript, but sometimes it's also about CSS. So let me just open this on Firefox. Give me a sec, it's loading. No, no loading. Okay, it's loaded here, not loaded. Okay, nevermind, I can just do DevTools right here. So the the clip path in CSS is this fancy thing where... Let me open it. Where you can animate the content that you want to show around an element. So in this example, you have a polygon and you can, you know, customize what exactly do you want to show about this element. So this animation is basically going from this state where everything is visible until this state, oops, this state where everything is even, but it's only visually. So when you put it in the right place, you have an animation like this open and close. Okay. So now we understand the magic here. The thing is it's visually hidden, but semantically it's still there. So how can we fix this? So let's go to the code. And we have here our case of actions where we have the button and the action items. And we have the transition, like if it's open, it expands the polygon. If it's closed it's, you know, zero, zero, zero. And the way to fix this is maybe we want some kind of, you know, display none by default and then a display block when it's there. So if we do this, we click and you know, it works. So if it's hidden and I tap, it's working. And if I click, it's working, right? The thing is, we lost the animation, right? Now it comes to the part where you can do some cool things with CSS. You could animate, for example, imagine let me change this, instead of display none, let's do visibility. Visibility heaven and visibility visible. So it's the same, but it contains the animation. So you could see when it opens that it does the animation, right? The thing is, when you close, you'll lose the animation because it goes immediately from invisible to visible and visible to invisible. So you kind of need a delay between the animation and the switch between both visibilities. And the way to do that is like, okay you have the transition, it takes 200 milliseconds and you can say look, this visibility thing it will take one millisecond, but it will only start two milliseconds after. Okay, let's do it on both cases. Sorry, in this case. So it will animate the clip off immediately but the visibility will only animate two milliseconds after. So, oops, actually I did it wrong. It's not here, it's here in this case. Okay, zero or one, whatever. So you click on it, it animates and you click to close and it will do the clip path animation and only after two milliseconds, it will come back. Does it make sense? This is a little CSS trick that I real like. So you can use CSS to control transitions between elements, in this case, the visibility. You can control with CSS when to change the visibility of an element. This is super, super cool when you want to make something accessible without compromising animations. So if I show you here the animation on the nav, on the dev tools, maybe it's easier for you to understand you have settings. On the settings, we have the animation debugger and you can do something like this. You can click on it and it tells you the animation. So you animate the clip path and at the end, it animates the other thing. So let me tell you, let me show you. So there you go, in slow motion. Let me do it once again. So you animate the clip path and only at the end you animate the visibility thing. This is super cool. Does it make sense to you what's happening here? You are animating the clip path and only at the end you animate the visibility here. So you can use this to bypass some animations without compromising accessibility. Another way for you to solve this case instead of using visibility is using an attribute called inert. So let me go back here with this visible, visible and remove this visibility CSS thing. So now what happens is like, again, it's broken because I'm tabbing and it's tabbing through the menu button. So another strategy is to use this attribute called inert. So this attribute called inert is like, when it's true, everything inside this element is not accessible, never. So let me put inert true, and now you can see like, I'm clicking actions and then tab and it jumps directly to this content. And then when I click on it and I tab, you can see that jumps again to the hiding content responsible because it has inert true. So when this happens, it ignores everything that is interactive inside it. So not only with a keyboard, but only also with the click, like if I try to click on this, it does not work because it has the inert true. So the trick that we need to do here is to toggle between inert true and false, depending on the status. So we want inert true if the action is close. So if it's close, this is true, otherwise it's false. Let's try it again. Click on it. You can tab, click, and then it jumps. Whoops. Something went wrong in my demo.

Let me try again here. Actions, let me just double check. The dom, okay, nav, you have the, no, it's not here. Let me try something here. So if it's open, we want this false. Otherwise we want this true. Let me try again. Actions, nav, inert false, inert true, okay. Now it's working, there you go. It jumps directly from actions to hiding content, I click on it. What? Inert false and now it does not click, that's wrong here. Demos can always be wrong. Let me go to my solutions very quickly to understand what's missing. Mm-mm-mm-mm. Oh, it's null, it needs to be null, yeah, I'm sorry. So we inert by default if it exists, it will always be applied. So if it's open it's null, otherwise it's true. I forgot that there's some of the things here that I forgot, sorry about it. So let's try again. By default does not have anything, and when it's open, yeah, when it's open does not have anything. And when it's closed it has the inert true. Let's do it again. Tab, it works directly, open, and now you can tab inside the actions. These inert attribute is super, super cool, it's one of my most wanted features for the browser. The thing is this inert attribute does not work by default in every single browser. So you need to import it in your application, like you need the polyfill for it, and in this case, the polyfill you can activate import it on the index.js, so you have the polyfill to make sure that it works not only in Chrome, but Firefox, Safari, so on, so on. It's super, super cool. The thing with the polyfill is that it's also super expensive from performance perspective, so be mindful of when you use it. If it's super complex, the type of DOM that you are trying to hive, it might impact the performance of your website. But for simple cases like this, man, this is perfect. Questions about this? Comments, no? Let me just check here the chat. Okay. Last but not least, regarding toggable interfaces that I want to tell you is like, sometimes we are just doing too much. There is this HTML, native HTML element called details that it's this one and you click on it and it opens, you click on it and it closes, you know? And there is no JavaScript here involved. So let me show you, let me go here, details, the way it's used is like, you have a details element with a summary element inside and then all the content that you want to use, that you want to show inside the details. So you click on it, it works, you close it, it works. No JavaScript here, this is a native HTML and you can use it for these type of things that you want, to toggle something simple. Thing is, be mindful that details are not menus or accordions or any other type of complex, toggleable UI. There's a little bit of discussion in the community around when to use or not details element and this article really explains when to use the details summary or not. But for the little things like these, like explanations of something, it's the perfect element. And you can also style it with CSS, you can animate it with CSS and JavaScript as well. You can do plenty of things with this literal element, okay? You can learn about it in this animating details reference. I have a question here. Do you ever recommend using tag index instead to conditionally remove focus from even elements? Brilliant question. So let's try that and you'll see the answer by yourself. So short answer no, but let's go to the demo. Collapsed here, let me remove this inert. So let's imagine that these action items... Where do you want me to put the tab index? And... In the links? Let me put it on the links. I'm assuming you want to put it on the links. So let's do tab index minus one. So if we do this, tab index minus one on the copy button, it means that if I want to tab, let me open here. Whoops. With this, it means like, if I want to tab, I only tab twice. Actually, let me use this tool to show you where I am at the moment. Tab stops. Okay, and one. It jumps directly to this one. It did not tab into this one. Then it jumps to the other one and it goes to this one, right? So technically, let me close this. Technically, yes, you can use tab index, but it's not only about keyboards. What about screen readers? Does it hide the link from the screen reader? Let's give it a try. There you go. So tab. Oops, oops. There is something wrong with screen reader, with the eye light around the elements. Let's try again. Ooh. Oops, let's not use the chat while I'm here, please. Okay, let's try again. Okay. Hit it. Come on, let's go, let's go, okay. Tab. Okay. Now, next one. Okay, it tells that I'm inside the navigation, a list of elements. List three items. There you go. Did you understand what's going on here? Although you have the tab index, the tab index hides from the tab keyword. But if you are using a screen reader and you are going element one by one, it will detect the copy element, even if it has a tab index, because it's still an element at the end of the day. So that's why the short answer is, no, do not use tab index when you want to hide elements from the keywords. Because probably if you are not hiding them. Not probably, for sure, you are not hiding them from screen readers, okay? So keep that in mind. Does it make sense to you, Andrew? Yes, okay. And, that's it. Let me think a little bit about these examples to just check if I didn't miss anything. I talked about this, about using inert. Oh, I want to talk about another thing here, which is about this nav element.

So, going back to the first one, we have a button, right? And then, this button, imagines menu, and it has, you know, home, about, contact. And, as you know, it should have a nav element, and then the links, you know, the list of links inside. The thing is, you are, in this case, you are putting this inert on the nav element, so let's make it, you know, inert. Let's not make anything right now. Right now, it's like this, right? When you use a screen reader, there are multiple ways for you to navigate the page. You can navigate through links very quickly, through headings very quickly, and through landmarks of the page, and nav is one of the landmarks. So, let me show you that, for you to quickly understand. So, if I open screen reader here, on VoiceOver, if I do control option U, it opens the router. And these router basically shows multiple things about the page. And people use this very, very often. For example, for example, it shows all the headings and I can quickly jump, oops, oh man. And it jumps directly to the page. And it jumps directly to one of the headings, For example, I click on it and it jumps directly to this. Another thing that it does is landmarks, right? And here you have all the landmarks, the main, and then all the articles. In this case, I do not have any label for the articles, but you can see this navigation here, right. So I click on it. Oops. I click on navigation and it jumps directly to the navigation. The thing is, the navigation it's hidden, right. Because you are jumping to an element that it's hidden and even worse is, if I put this inert here and I save it, the navigation will be hidden as you can assume, because it has inert. So control option. Control you. Now you can see that the landmarks, the navigation landmark is not there. So imagine that this is a real menu because the menu is hidden. You are hiding the menu from the users, which is bad because you want your users to access the menu very, very quickly, like if they want to. So there is a mistake here with the HTML as well. So, and the mistake is that you are hiding the nav directly. So when you have, for example, this button, the button is part of the navigation. It's the element that triggers the element for the listing inside the navigation. So all do you fix that, use nav outside, not inside. And then this is just a div. So all of this is a nav. It's a nav. And also unrelated, but still related, you can name your navigation. So you can say like, are you label actions. So for the screen reader, they will say, look, this is the navigation actions. So let's save that and go back to the screen reader. Turn on the screen reader. Please do not comment in the chats. There you go, control option, you, there you go, actions navigation. Now I will click on it. Right, let me just scroll a little bit. Actions, button. And then I go after it and it goes to the actions button. That's actions, button, copy, button, list three items, list three items. Can you see the difference here? I know that this is all about JavaScript, this one is about only HTML, but make sure that when you create navigations and you are toggling elements inside the navigation, that you are not hiding the navigation itself. You are hiding the elements inside the navigation so that the user can access a navigation very quickly, even if it's hidden. Questions here? You want me to explain again or explain in a different way? No? Does it make sense? The silence. Okay, I will assume that it makes sense. So, short answer here, navigation always on the outside. If you want to label your navigations, you can use ARIA label. Actually, now that I think about the question that someone asked about, oh, when to use screen reader, only SR only versus ARIA label? In this case, you need to use ARIA label. You cannot use screen reader. SR only in this case. You could do something like you have a span where it says actions, and you could put an ID here, like actions label or nav label, and it could use ARIA labeled y where you pass the ID of the element. So that can be a way where you use the SR only element instead of ARIA label, but still you still need ARIA label at the end of the day. So, two different ways to achieve the same thing. For example, if these actions was really visible, you don't need to repeat yourself and you could link them using an ID.

Okay. Now, what time is it? Almost time for a break. Questions, do you want to take a break now? A 10 minutes break or we'll do one more exercise with error handling and then we'll do the break. You can react with thumbs up to continue and thumbs down to take a break. Or you can use a chat. Let me see. Okay, let's continue then, we'll take the break after it.

Now, next section is your end link. Let me go here. So in this case, we have a simple lottery button where you click on it and it loads, you can see that it loads and well, more luck next time. You can click again. And oh, no, the server is down. Click again, maybe it's this time. Okay, it's down again. Well, you click and randomly it will output something. This time, I'm out of luck. Yay, I won the lottery. Or you can reset. Visually, you can understand the state. You can understand when it's loading, when there is an error, when it's success. But once again, if I'm using a screen reader and I cannot see the page, like let's make it real. Like screen readers are not only for blind people. People with a visual impairment might use screen readers as well. So let's do a quick test here with CSS where I will just put this. I will do some filter blur, 10 pixels. Well, good luck understanding the results right now. This is the real life of some people. So let's open our screen reader and try to navigate this. So I can't see exactly the page, so I'll do control option U. I'll go to the headings and I will jump to the loading state. Okay, let's go. Okay, let's go on. Okay, let's get loaded then. Press. I have no idea what happened. I can see something red, but what exactly was it? Let's try again. Nothing happened. I'm so lost. So with this small exercise, I think you can understand what this page is trying to tell you. I think you can understand what's wrong here. You must also announce when something in the page changes, and this is what we call live regions in accessibility. A live region is something in our page that, you know, it's alive and it can change, dynamically change, and we need to announce those things. So how do we do that? With ARIA, again, ARIA to the rescue. So let's jump to the demo three. And here we have our, you know, loading state, a quick overview of this code. We have a button with onClick. The onClick loads the lottery and, you know, it has some fake lottery, it waits a little bit, and then it sets the result. And if there is some error, you know, it sets the error. And then you have the DOM here at the bottom with empty state, the loading state, and the result, last but not least, the error in case it fails. So let's start with the loading. So when I click on it, it's loading. How can we announce that it's loading? Somehow, we want something like something like loading to our screen reader users. But we don't want it, you know, we want to be here when it's loading, right? So we would do something like this. When it's loading, it will show the loading text. And we want to announce it to the screen reader. So the way to do that is using ARIA life. These ARIA live attributes accepts three values, assertive, off, and polite. So the off doesn't do anything, it doesn't do anything. The polite, it will announce this text when there is nothing else to announce. And the assertive, it will announce this text immediately. So let's do the assertive, because we want to right away announce that it's loading. So let's start with it. ARIA live assertive, loading. And let's go to the demo. Whoops, that was fun. Here, let's just double check here. Okay, reset. Loading text. Voiceover on clone A111. Not sure if it will work right away because sometimes I need to refresh the page, but let's see. Battery button. I will click on it. Loading. There you go. It announced the loading text. Voiceover off. Just because of that, ARIA live assertive. Now, even better. Maybe, okay, we want to announce it, but we do not want to make it visually there, so we can use the SR only. So the element is there, but only for screen readers. Let's give it a try again. Voiceover. Loading text. Get loading. Okay, let's press. Loading. Okay. Voiceover off. It did its job. So basically the trick here is to use ARIA live in any type of content that we want to announce dynamically.

For example, for example, in the error message, so error ARIA live assertive, and on the result as well, ARIA live assertive. Just by doing this, to, to, to. Again. Voiceover on. Loading space. Get lottery button. Control option, space. Loading. Okay. More luck next time. There you go. It worked again. Loading. More luck next time. The same. Loading. More luck next time. Oh man, no errors. Loading. More luck next time. Really? It's addicted? Loading. The server is down, please try again. There you go. Voice over off, Linda, iPhone 11 has... Who? Okay. So with this trick, you can announce dynamic content literally right away on the page. Things to take into consideration when you use this. So for example, imagine that the results in real world this would be like a filter and it outputs 20 results of articles. For example, blog posts. You do not want to use ARIA live in the wrapper around everything because then it would announce everything inside. So usually you only want to use ARIA live in short announcements. So imagine that this result would be massive. Something that you could do instead would be something like, okay, if there is a result, I want to load those N numbers, like, load the five articles, for example, or five results or something like that. So you basically, results. So basically you are only announcing a short summary of whatever happens in the page, okay? Make sure that, you know, ARIA live announcements must be strings, cannot include, you know, headings or buttons or anything else because it will not be announced. It's just a text string. Another thing to take into consideration is, do not use ARIA live everywhere. You know, sometimes you just want to use it on, really on loading times, or if you are announcing a loading each time the person is typing something or searching for something, make sure that you only announce it at the end when he stops typing. Otherwise it will be very annoying to announce the text over and over again while you are typing, okay? When to use polite versus assertive. Usually I use assertive when it's really essential for whatever the user is doing right now. Like if you click on the button, you want immediate feedback, so it's an assertive. But if it's like you are announcing a new message, a new notification, well, that can wait. So in that case, that new notification is polite, or you are announcing, you got the idea. So that's an example. But when you deal with search or forms, which is very critical to the path, to the current path, assertive usually is better. But even better than that is to test with real people and they can give you their real feedback if it's annoying or not, the assertive versus polite. Now let me check the chat. What happens if two elements uses areYaLive assertive at the same time? They are announced right one after other, one after another, sorry. So let's do a quick test here. So imagine that we have a loading and then we have another loading, a lot. Let's see how this works. Usually what I'm expecting is to announce the loading and a lot one after another. But now I'm curious. Oh, okay. Oh, actually no, it only announces the second one. It only announces the second one. That's a new till for me. Today I learned. Let me just, by curiosity, try this on Safari because usually VoiceOver works better with Safari than Chrome because it's meant for Macs. But let me see how it goes here. If it loads on Safari. Give it a second. Five more seconds. Oh, five more seconds. There you go. Oops, it's not this one. Hey, do not use the chat while I'm using the screen reader, please. Okay. Let's give it a try. Press. Yeah, it only announces the second one. It does not announce the first one. Voice over off. That's a new thing for me today. I didn't know that, I must confess. Let me just, are you live? Loading, are you live? Yeah, loading a lot. It will only announce the second one because both appear at the same time. But now, let me try polite, for both. Polite for both. Is it... Polite for both. Voice over on and stop. Get lottery button. Okay, button, click. Press get lottery button, loading a lot. There you go. With polite, it announces everything. And do you notice the difference? Like when you click, it announces, okay, you press the button and then it announces loading a lot. Once again. Press get lottery button, loading a lot.

Voice over off. There you go. I hope it clarified your doubt and I learned something new today as well. So next question. What happens if you have multiple audio live elements on the page? There you go. Now you have the answer for it. If it's polite, it only announces the less polite that it was added to the DOM. Sorry, if it's assertive, it only announces the less assertive. If it's polite it announces everything one by one. Can you change to longer text? Can you change to longer text? Yeah, the text can be as long as you want. The text can be as long as you want with multiple lines if you want. As long it's only text, you know? So let's give it a try. The thing that will happen is if this text disappears, in the meantime it will not announce everything and it will jump to the next thing that it needs to be announced. So let's give it a try again. To enable screen readers, all new states. Get lottery button. Press? Press, get lottery button. The text can be as long as you want. The text can be as long as you want. Woo, it stopped. Okay. And it did not announce you won the lottery. Let me try that with Safari. Oooh. So it seems like it started announcing. It took a while to stop announcing it, and it did not announce the new one. Let's try it with Safari. Now we are testing the screen readers. That's the thing about screen readers. They do not always work as you expect, and this is only voiceover. There are other types of screen readers out there. So let's give it a try. Get lottery. Press, get lottery button. The tech, oops, the server is down. Please try again. There you go. In Safari, test the behavior I was expecting. It would stop immediately and announce the new one. Again? Press, get lottery button. The text can be as long as you want. The text can be as long as you want. The text can be as long as you want. Hmm. It announced, yes, you won, and then it continues, the text can be as long as you want. Interesting. Hmm, let me do one more test. Let me put both assertive. Assertive and maybe not that long, but still long. And let's see, that's the only, the last test I do. Okay. Loading state. Okay, let's click on it. It didn't. There was something here, because it was assertive, but did not read it was assertive. Let me check here the DOM, to see if it's really assertive. I got the impression that this is still polite. Button reset, then you have the div, and it should be here somewhere. Get lottery. Polite. Okay, I need to refresh the page. That's why it was different. Let me check the chat. I have a feeling if you have two assertives, it reads at the same time. Well, it doesn't, at least not in Chrome, but once again, it might change from screen reader to screen reader. The best way is for you to test. I asked you to make the first test longer, the second one short. I did not understand what is the first text, the loading text? Okay, let's just let you. So I'm sorry, so I mean that because you said that if you have two assistive, the second one gonna read and the first one gonna be ignored, right? So I asked you to update the first text longer and the second one is shorter. So if your theory is right, the first one's gonna be ignored, right? Let me try that again. So this one, you want it to be shorter? No, the first one is gonna be longer, but can you all should duplicate to make another assistive and each shorter? I got you, so like, this is short. Yeah, so I... And this one is a very long one and see how it reacts. Yeah, yeah. Okay, let's give it a try. I'm enjoying this. I'm learning here as much as you are because it's always a surprise when you are dealing with these little corners, so. Reload 8111, in jsapp.yaml sum of 2022. Okay. Come on Safari, be faster. Okay, there we go. EPS, get lottery. Let's go. This is short. No, it's only, it's only announced the second one, although the first one, it's all also there. So in this case, it's only announced as the second one even if it's shorter. Okay, here we are testing, you know, testing our screen readers and the behavior of screen readers but in ideal worlds you only use one assertive at the same time and it's simple with a simple, you know, loading and it should work fine but it's always good to test those scenarios. So, so far we learned about, you know, the loading states, like regions. Someone in the chat post a comment about the rules of RELive and one of the things that it says is that the user agent or in this case, the browser may choose to clear quick changes when an assertive change occurs. That's why when we use multiple assertive loadings, like loading a lot, that's why only the last one was announced.

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.

You click on it and it even focus the label and other things that you can do. For example, okay, the description is, we promise to not spam you. It has a role, which is like a text box, but in this case is an email. So it's missing the role to say that it's an email. It says, like, okay, it's focusable. And then we have multiple things.

For example, one thing that we can notice visually is that it's required because you know, it has this little star, but in the DOM for the accessibility tree, it's still false. So we need to fix it as well. So again, ARIA, ARIA requires true. And we can even say if the input is valid or not using ARIA invalid, where it's, you know, true or false. And we can make it based on the email error. So if there is an email error, it's true, otherwise it's false. And with that, let me open it again. Here we have the input. Okay, it's required true, it's invalid. And if I reset, it says, okay, the error is gone and it says invalid false. And then you have all the information about this input.

Questions about these little accessibility tree thing that you can use to inspect the accessibility of an element before jumping into the screen reader? Let me check the chat here. Why using a span instead of a label on the input example? Why using a span instead of a label? Oh, that. So the span was a mistake. We must use a label. Okay. But if you want, if you really want to use a span, you can also use the span, but for that, you cannot use the HTML4. If you want to use a span, you can use aria-labeledby, then you pass the ID, like, label, email, label and then you put here the ID, okay? This also works. Let me go back here. Let's do the test. Input, label, by, email, label, aria-labeledby, and it detects that it's your email. Okay? One advantage of using label instead of the ID, yeah, instead of the ID, it's, let me go back here, it's the clickable area. So, with the label, you can click on the label and it will focus the input. That's one spec about the label. If it's, you know, just a span, you click on it and it will not focus the input. Okay? So, that's the only, that I'm aware of, practical, you know, behavior difference between both examples. If we don't have a name in input and we don't have label using ARIA-LABEL will... Yeah. So, exactly. In case you don't have a visual label, the only way for you to, to name it is using ARIA-LABEL and then you can say your email. That works as well. There are multiple ways on how you can name an element. You can use a label, you can use the ARIA-LABEL, ARIA-LABELEDBy, so multiple ways. Here in this case, like, even if we do not have the label visually, we could use the class name with the sr only. So semantically, we have the label. It's connected but it's visually hidden and this still works. Okay? Do we need ARIA-DESCRIBEDBy if we already have the label and HTML for? Yes, we need the DESCRIBEDBy because this label only announces your email. It is nothing announcing the description. We promise to not spam you. So that's why you need the ARIA-DESCRIBEDBy to provide the extra information about the element. Next question. Oh, it was already answered. Thank you. I think now it's time for demo. Please, do not type anything on the chat while I'm doing the demo. Let's go. VoiceOver on. Input information selected. Your email status, required, edit text. We promise to not spam you. See. Did you notice the difference, the pause between the label and the description? So when it's a label, it announces immediately, when it's a description, it pauses a little bit and then announces the extra information. This type of pause can even be customized on the VoiceOver settings. And like, oh, make a short pause, a longer pause, or you can even ignore that type of extra information. So, now you can have control over it. Now, if I type something... And then I do blur. Well, it didn't announce the email is not valid. By now I think you know how to solve this, right? So in this case we would like to add some ARIA Live saying assertive. So when we blur the element, it will announce, look, hold on, the email is not valid. It will tell the person that something is wrong and they should not keep on. There is something else here missing. Can anyone guess what's missing here? No, nothing on the chat? Okay, let's go to the demo. ARIA Live, no, the ARIA Live is already here on the error. So it's not ARIA Live. Something about announcements. Okay, let's go to the demo. Again, please do not answer now because I'm doing the demo. So, reset. Okay. Tab. Let's type something. Tab. Okay, fair enough. Let's imagine, okay, I know the email is not valid. Let's do stuff. You know, let's navigate, whatever. And then I'll go back to the input. Recessed. We promised an email address insertion at end of text. Your email start requiring valid data at a text. We promised to not spam you. So, in this case, what happened is, it did not announce the mail is not valid when you focus the input. So, in this case, you were expecting to announce both this description and the error text.

Okay, that was the thing that was missing. One of the things missing. So, in this case, we kind of want the description to be the error and the actual description, the hint. One cool thing about describes by, and labeled by, is that you can pass multiple IDs. So, you could say that the ID is, or the description is, a mix, like a match of both the error and the hint. And with this, it will announce both one after another. Let's give it a try. To enable screen, okay, let's go. Your email stock required, edit text. Repromise to not spam new. Okay, all fine, I'll blur. The email is not valid. Okay, it announced that the email is not valid. Link set error. Now I'll go back to the input. Your email stock required, edit text. The email is not valid. We promise to not spam new. See, that was the missing thing here. Another extra thing that we could do here is to hide this star from the screen reader. Like because you know Zoe, it says your email star. Well actually don't really need to say, you know, to announce a star. So you can do something like span again. In this case, we do not want to visually hide it. We want the other way around. It's there visually, but we want to hide it from the screen readers. And the way to use that is using aria-heathen. aria-heathen true. So the screen reader will ignore this element or this text. And it will sound like this. Your email requires IDF edit text, art. See, your email, without the star. Little things. So what I want to tell you here is that, nowadays if you want to make a form fully accessible, you know, with the arrows and dynamic things on blur, on change, all of that, you need JavaScript to make it full accessible, you know, to make it more inclusive. To really, to ensure that the person using this form or feeling this form doesn't feel lost, okay, when doing that.

To really, to ensure that the person using this form or feeling this form doesn't feel lost, okay, when doing that. Someone asked on the chat, do screen readers include CSS pseudo-selectors after? Yes, they do. They do, they do on Chrome. That's my short answer. I'm not sure if they do everywhere. We can quickly, let me check the time. Okay, we could quickly test it. Let me, let's imagine that this paneer, you know, has some CSS, whatever. Something CSS, call something CSS. And it is, you know, a before called content, well, something, right? Something, something. And without RDA then. Okay, so we have your email, something, let me put this outside. So, we have your email, actually let me put this outside of everything. We have something like text, hello. So, we have hello and then the prefix saying something. Let's see how it goes. It will announce everything, that's my bet. I remember that at least on Chrome, but yeah, there you go. It announces everything. And I would say that on Safari, it also announces everything. So by default, yes, it announces. Actually, now that I remember, you can even do it to not announce something on screen reader. So, imagine it would announce something visually, but for screen reading, you do not want to announce anything. And there is this little feature, if I'm not mistaken, I think it's a dash, a slash. So we have the text, the visual text and the accessible text. So, let's imagine that for the accessible, it will say old instead. So visually, it's saying something, but for the screen reader, it'll say something or empty if you don't want anything. And with that. Forceps to enable screen reader support. Old hello! There you go. Old hello, this is our view. This is how you trick, auto-customize the pseudo elements to say something for screen readers, okay? So many times I see myself, putting your some characters or some cool things or SVGs or whatever, and then I want to hide it from screen readers. I do this trick, okay? Okay, this has nothing to do with JavaScript, but accessibility is a little bit of everything. I think that's all I have to tell you about labels for now. Make sure that you describe your inputs with the description that it's when it's required or not, with when it's invalid or not. You can, you know, even customize the type of descriptions that you provide and the time when you provide them. Avoid things like the lazy thing of wrapping everything around the label. Like put the label here and the label at the bottom. This? Do not do this. Okay. Try to avoid this. Why? Because if you do this, when it reaches the label, it will announce everything at once. Each time you are typing in this input, it will announce everything. The label, the content, and all the description. And sometimes you want a little bit more of control over what you announce and when you announce it. Okay, also because if you click, for example, here in the description, it will focus the input. And you really don't want that. Or imagine that you have a link or a button. You click on it and then it's like, oh, it will open the button or it will focus input. You know, it's a little trickier. Okay, so if you can split things. So it's a div and then a label and input and the description, each one separated. And then you connect all of them with ARIA, okay? That's all I have for you with inputs. Let me just check the chat again. Oh. Okay, all good for now. So, last topic. Some extra time? Yes, we still have 15 minutes. Before we go to extra time, I want to tell you a little bit more about Accessibility in Words. So, let me open this here. Before we move on, I want to talk about the difference between accessibility, usability, and inclusivity, or inclusion, as you prefer. And sometimes people say, oh, everything is accessible or everything is usable or inclusive or what is the difference? And I thought about this quite a lot and I was like, yeah, that's a good question. And this is my answer from what I've been understanding. So accessibility is making sure that something is functional. For example, that this select is really a select that you can use with a keyboard and it's a native select, or at least, it's super accessible. No leaves or no custom buttons and stuff like that. It's accessible. Usability is thinking about the UX of your element. Like if this is a select with only three options, why not making it a radio input? It's easier to use. So accessibility is about making something functional. Usability is about making something easy to use. And then the last one, inclusivity, is making sure that whoever is affected by this, it's affected in a fair way. So in this case, it's making sure that in some countries you have some regional price, where it's for example, it's cheaper. So that you are not only being accessible, not only being usable, but you are also thinking about inclusion. So you have fair access to everyone around the world. Does it make sense to you? These three differences. Yeah. Questions, thoughts? No. I always think about these three when I'm trying to explain the difference between these three concepts. They all are relatable, and at the end of the day, it's all about inclusivity. In order for something to be inclusive, it needs to be easy to use, and it needs to be functional. Another thing that I would like to talk about, and it's the last thing I want to talk about before jumping into the extra time section, is this. When someone tells you that HTML is easy and don't bother to learn it, remember, there are some annual studies around the top one million websites out there, and there are a lot of accessible issues out there, like low contrast, missing alt text, empty links, missing form inputs, empty buttons, missing document language. All of those things can be fixed quite easily using HTML or even JavaScript. So, take that into consideration. And the very last thing I want to tell you about is remember how we started the workshop with the myths, you know, that no accessibility is for blind people, or it's a tiny minority, or it's a health problem. Remember these assumptions? Why do these assumptions exist? And for me to answer this, I need to talk about something else. And this has nothing to do with accessibility.

Remember these assumptions? Why do these assumptions exist? And for me to answer this, I need to talk about something else. And this has nothing to do with accessibility. It has nothing to do with being a developer or a designer. This is about us being people, being a person, and you know, it's human rights. So what I want to talk about is ableism. And ableism is basically when you treat able people as a norm, therefore you exclude disabled people. And you know, it's when you treat someone as less than, and this can happen, you know, unconsciously. So be aware of your ableism behavior, you know, stereotypes or misconceptions or, you know, generalizing something or someone just because they are not, you know, the norm, you know? So try to have that in mind in your day to day.

And the thing, you know, the thing why ableism exists is because of our, you know, society, our model that we live. There are two models. There is a medical model and a society model. And the medical model is like, oh, the individual is a problem of this person is blind, so we need to fix them. We need you know, to cure or to avoid or whatever. And that's wrong, you know, because there is nothing wrong with adding a disability. What's wrong is the society around, the ecosystem around. So, you know, from a medical model, you need to change your mindset for a society model. If there is something, some type of ability from a person, you need to adopt the ecosystem, the environment around. You know, the buildings they need to have elevators instead of stairs. In your company, you need to have a mindset of, you know, a nice, kind culture, sense of belonging. And all of that is around the society. When there is something about accessibility, the problem is not the individual, it's a society. And that's what we need to focus on, okay? So you can forget everything you learned so far in this workshop, about, you know, code and HTML and all of that. At the end of today, what I want you to remember outside this workshop is how you behave as a person outside, you know, try to not be ableist, try to include everyone and treat everyone as fair as possible, okay? And you can do that as a team, even in your job, back to a developer. You can do it in a team, with your designers, you can tell them, Look, accessibility will improve your skills, not limit them. As developers, please don't fight me, but HTML and CSS are also real languages and are as important as JavaScript to build, you know, modern websites. For QA experts out there, we almost didn't talk about automated tools, but the thing is, automated tools only catch around 30% of accessibility issues. Okay, so you really need to do manual testing. You need to understand people. You need to care about people if you want to make your website accessible. And last but not least, product managers. Tell them that accessibility, is a requirement, is a human right. It's not a nice way of, or a bug, you know, something, you know, a feature for the afterthoughts, you know. If you find something that it's broken, it's a bug. It's not a nice way. Okay. And how to make sure, you know, how to know if your website is accessible. Three tips, try to accomplish it using only the keyboard. If you can do something only with the keyboard, you are already in a good place. Try to use a screen reader from time to time. You know, I use a screen reader every day. I use it when I'm creating new fancy things, new custom components, or exploring something more advanced. That's when I use it. Otherwise I use a lot of accessibility tree. It helps already, but less, less, but always, but even better is like asking someone different than you to try your website. Okay. Oops, sorry. And that's my last words around accessibility. Now let's jump to the extra section of the workshop.

Okay. Questions, comments so far around this? No. Nope. Okay. So time then, demo number four. Let's open here, here, close this, and this. So, custom interfaces. Here we have a model. We click on it, and it closes. It looks fine, right? Let me go to the screen. Click, close. Again, it works fine with the mouse. What about the keyboards? Let's open it. And now let's try to close it. Trying the escape key. It doesn't work. Let's try to navigate to the input. I need to tap. I need to tap again. Okay, now I'm there. Now I'm tapping, and I'm already lost. You know? The tab is somewhere behind. What about clicking outside, if I want to click outside? It doesn't work. You know, there is a lot of things that you need to take into consideration when you create a model. Probably you remember other type of things to make a model accessible that I didn't mention, but the message here is like, sometimes creating accessible custom components is harder than it looks like. For example, when I was implementing my own model, I was like, okay, what do I really need to take into consideration? And I was like, man, this is a lot of code. Maybe there is something else in the community that I can use to create the model accessible by default. And then I found a couple of solutions out there. And I was like, man, what's the difference between this? They are all the same, but all the difference, So I went to one of them to react ailey dialogue and I posted the message. Look, this is super cool. Thank you for doing it. But there is also other options like this and this. What's the difference? And the author answered me and they basically said this, I'm just scrolling all the things that you need to take into consideration when you are implementing a model. And it's just a model. Some people say that it takes two lines of code to create a model. Some people disagree. There's a lot to take into consideration when you create a model. And there is a lot to take into consideration when you create any type of custom component. A model, tabs, cardians, tool tips. So when possible try to use some package from the community that is already built with accessibility in mind. But also taking consideration when someone says, oh, this is accessible try to dig deeper, why is it accessible? What did you took into consideration to be accessible? There is this article, claims versus reality from accessible components. And this is, this article is super cool to tell you what type of things you need to take into consideration when you look, you know, into a new package out there that it says it's accessible.

Some questions that you need to take into consideration, okay? So, take a look at it. And my short answer for you is like, there is already some packages in the React community, super cool. Like, Rich UI, it's this one, it has a lot of packages that are accessible by default. One of them is Dialog the Model. Another one is from Adobe, which is called ARIA, React-ARIA. Where it only has, not only has components, but also has a lot of hooks, for example, to deal with keyboard, or to deal with hover, or, you know, date pickers, so on, so on. A lot of things that helps you to create these type of custom components with accessibility in mind. Okay. That's why, so, in this workshop, we'll not learn how to make a model accessible. Because, as you can see, it kind of takes a while. But, what I want you to learn is like, when you create something custom, try to look into the community, and learn from them, instead of trying to reinvent the wheel by yourself. Okay? Oh, can you share the issue? Yeah, sorry. Oh, the issue is already here. So, the issue for the considerations is this reference, dialogue, accessibility, considerations. There you go. You have the issue for you to read before you go to sleep. Okay. That's all I have to say about custom interfaces for now. The next part I wanted to talk about is generated data. So, in this case, we have three cute cats, and each one of them is the image with the name of the cat, and the view link. And the CSS is, the HTML is quite straightforward. A list with the image, and the link. Visually, again, it looks fine. It's all accessible, it's working. It has a link, it has an image, so this is not about accessibility. Now we are talking about usability, so how easy it is to understand or use this. And it fails on the screen reader part again. For example, here we have each image as the alt attribute, saying like cat and the name of the cat. And then you have the name of the cat again, and then you have the link. So my question is, how useful is this image alt here? Like you are just saying cat Tokyo, cat Oscar, cat Luna. You are not really describing the image, aren't you? Especially in a screen reader, which will tell you something like, oh, image, cat Tokyo, then Tokyo, then view link. So if it's not useful, you can just, you know, put it empty, empty alt. There's nothing wrong with it. This is very common, especially in React applications where I see this type of thing and oh, you don't have really a description. So you'll just say cat or you'll say even worse it's like cat and then index, because for some reason you think that alt should be unique in the page. So these type of things really do not make any sense. Like it will say something like cat zero, cat one, cat two. Like people who use, or will take advantage of this alt, you know, are people, not robots. So whatever you write in this alt caption, make sure that it's meant to be read by a person, not by a human. And if it's not useful at all, just skip it. You know, if you don't have nothing to say, just say nothing, you know. So in this case, image with an empty alt because you don't have a real description, like cat looking at a picture or cat looking something else, you know, or black and white picture of, you know, your cat. If you don't have anything else to say, just say nothing. Okay. That's one thing about alt. Actually there is one, I forgot to add here the reference, but there is write alt image with emotion. And no, it's not emotion. CSS, CSS and JS is literally emotion. And this article is super cool in giving you tips on how to write, you know, great inclusive descriptions for images. Let me put that on Discord. There you go. The second thing I want to tell you about this generator data is this link. So it tells you like view, view, view. When you use screen readers, as I shown you before, you have multiple shortcuts to jump in the page, headings, landmarks, and the other one is links. So if the link is always the same, it is not very usable for who uses the screen readers. So let me show you. So if I go to the router of VoiceOver, Control Option U, you have the headings. And then if I use the arrows right and left, you'll go to the form, landmarks, articles, links, and here you have all the links in the page. And here you can see three links that say exactly the same. View, view, view. Now imagine that this is a page full of blog posts and all blog posts say, read more, read more, read more, read more, read more, and read more again. It's not super cool, right? It's nice if you can make these links a little bit more intuitive. No items or links in the closing link for stock. And the way to do that, you already know how to do that. So, in this case, it could be view, and then the name of the cat. And this name could be with the class name. Yes, art only. That's one approach where you can use it. Another approach could be using ID label, or ID labeled by where you connect the ID to the link. You know, I have multiple ways. The final thing that you need to memorize is like, okay, you need to make this unique. And now, if we debug this view link, we have the view and the OSCAR insight, and in the accessibility tree, if we open it, it will tell that the name of this link is view OSCAR, because it's the content, although we do not see it. And for the screen reader, VoiceOver. Control option, Q, Link's not here. And now if I scroll, you can see, view Tokyo, view OSCAR, view Luna, and it's more accessible, okay? So the link itself is already accessible. Again, this is not about accessibility. It's about usability, okay? VoiceOver on. So take that into consideration when you are generating data. Once again, do not put the index here. Like view one, view two, view three, try to make it a little bit more human, okay? Let's jump to the last one of the day. Animations in JavaScript. Let me close the generated data, custom interfaces, animations. So here we have this little square always rotating, and let's reveal the lucky day. Click. And it's Friday, the lucky weekday. Let's click again. This animation, you know, and it's Friday again. Okay, the thing that I want to talk about is you create this animation using JavaScript. I can show you the code. So you have revealed number, callback in the button.

And, you know, it has the shuffle delays that does some magic, you know, with the text where it also sets the text every 10 milliseconds or something. You do it for half a second, like not half a second, one second enough. Let's increase it a little bit, and then it's stop shuffle and it always say, look, it's Friday, whatever. But you have here some type of animation. And for some people, this type of animations, and in the real world where you have some more advanced animation, it can be not good. You know, some people might feel busy with it or, you know, prefer to not have any type of animations on your website. So how can you take accessibility into consideration when you create these types of things?

Now, for those who don't know, there is this CSS media query where you can detect if the person does not want motion or animations in the website and change the behavior, the CSS behavior, depending on that media query. For example, do you see this little square? You can disable it. Disable animation, let me show you how. Where is it? Go to CSS, go to definition. And you have something like, you have the animation and if the match is the media query, prefers to reduce motion, reduced, then it does not animate. That's the trick here. And now the question is, how do you reduce the animation? So it depends from computer system, operative system, but in Mac, you go to accessibility, display and then reduce motion. And when I click on it, I forgot to save this. What's happening here? Reduce motion, it was reduced, why it's not working. Reduced. Oh, why demos don't work? Animation n prefers with this motion reduce. Oh, I think... You have to add a D, reduced. Yeah, but even though it was not working, I think I need to refresh the page because I'm dealing with CSS in line. Not CSS in line, but the CSS prop from style components. The hot reload does not work very well here. No. Reduce motion, it's still rotating. What am I missing here? Let me go back a little bit with the reverse. What? I knew the reverse was working. It's reduced with a D at the end. Without the D at the end, I've never used the reduced one. That's why I don't know. Reduce with a D, without a D. Reduce. Let me go here. Now it's working. Great. Great code sandbox. Okay, I'm assuming that there's something with the code sandbox. So, now, if I turn on the reduce motion. Okay, there you go. So, now it's working. So, you have an animation. With CSS, you can reduce, or remove the animation. Based on this media query. But instead of fusing this media query, I like to do the other way around. I say that, by default, there is no animations, and if there is no preference, which was the opposite, no preference, you add the animation. So, this is a no motion first approach. And the main difference is, like, for example, old browsers will not have animations. Usually old browsers are slow devices, so if you can avoid animations, you should avoid animations there. So, I prefer this approach. The cool thing is that you can bring this into JavaScript. And the way to do that is using the media query on JavaScript. And with React, you can use a hook for it. So, let me go through the hook. I already have the hook for you, so we don't need to build it all again. But you have the UsePrefersReduceMotion, and you can have some reduced motion. And there you go. And this reduced motion, let me import it here properly. And this reduced motion will be true if you do not want motion, and will be false if you can add motion. So, let me quickly show you here. So, motion. If you have reduced motion, you say Reduce, otherwise you say NoPreference. There you go. So, NoPreference with the motion, and now let me put here ReduceMotion. Reduce, so no motion. And now you can use this type of hook, this hook to customize your JavaScript behavior. So, in this case we want to simplify the animation. Before we do that, let me really show you what the hook does behind the scenes. So, this hook, I shameless copied it from Joss Kamia. And he has this snippet explaining the hook in detail. But the global idea is you have this window match query and you pass the CSS query exactly like on the CSS and you check if it matches or not. I can even do it like this to be even simpler. So you can do window match query, match media and you pass the query inside. So in this case, prefers with this no preference and it returns an object. And then you just need to say like match to see if it matches. And it returns true in this case. And if I put with this motion no preference, it will return false. Right? And now the trick is to connect this with hooks. So you have a use effect where you create the match media and you have a listener on when the media query changes. And depending on the listener, then you turn on or off the Boolean state. So you have a local state, or is it prefers reduced motion, which is true or false. And then you toggle it. And then you can use this hook, whatever you want in your application.

Now, with that done, let's go ear back. We have this reduced motion and we can say something like, okay, if the motion is reduced, let's do something simple. Otherwise, let's, you know, do the fancy shuffle, this. And it can be something simple, like, I don't know, the simplest thing like set text loading, that's it. And with a fake await as well. So if motion reduced, just let's say, loading, otherwise we'll shuffle it and will go crazy. So, reset, reveal lucky day, loading. And then it's Friday.

And then it's Friday. Now let's put motion again. Reveal lucky day. And then there you go, you have animation again. So when you are dealing with fancy animations on your web page like loadings, fade ins, fade outs, you know, any type of fancy, I don't know, fancy animation that you can imagine, take into consideration people who do not want motion in their websites, okay? That was the last trick I had for you. I think, let me think about, oh, there is one last thing. In case you want Google Chrome, you can simulate, emulate a lot of things in Google Chrome. In the Dev Tools, you can go to the Tools, More Tools, at the top, and you have Rendering, where is the Rendering? Rendering option here, you click on it and you can emulate quite a few things. For example, you can emulate dark theme, light theme, where it's the, there you go, light theme, light, light or dark. And you can also emulate the reduced motion. So you can say, reduced motion, and now there is no motion. Reveal lucky day, loading. It's Friday. Now, let's put the remote emulation, and now we have motion again. So that can be useful when you are debugging in Chrome. And that was it. Let me check the chat again. Yeah, when you are writing tests for this, you need to mock the window so that it also matches the value, true or false, because the window match media does not exist on tests, because it's not real DOM there. And, well, that's it, I have for you. 20 minutes left for random questions, anything that you want to learn more about accessibility. I have the time for you now. You can use the chat or raise your hand, those work fine. Or you can clap, thank you. Um, questions? Go wild, anything, anything that they can answer under 20 minutes, I will answer. No, okay, maybe I have a question for you then. Let's imagine... Oh, okay, someone asked the question, so let me answer that first. Do we have some tools to evaluate how accessible the website is? So yeah, there are tools to evaluate, not to evaluate but to catch accessibility issues, but those tools only catch around 30 to 40% of the issues. And that number, I didn't say the number from anywhere. You have the reference here on the slides. But nevertheless, it's always good to have a tool to assist you. For example, my favourite tool to inspect websites is this Accessibility Insights for Web. It provides a lot of tools and even automated checks. Like you can click on it and it will tell you like this one doesn't have any error. But for example, if you have a button without a name or something like that, it will tell you, look, this button does not have a label. For example, let's go really quickly with this one. And where we have, we don't have ideal label. There you go. We have a button without a label. This tool will catch it. I don't know if I need to refresh the page. Oh, I need to refresh the page. Let me... B1, then you have the button. Get started, get started, raise the button. No, B2 sorry. Are you like, no ARIA label, no ARIA pressed. Oh, you still have this. Go, will try again. Oh, there you go. It tells you, look, there is one error here and it gives and it says, look, it does need a text and it does not have a text. And it says what is the success criteria associated with it. You can inspect the HTML to understand, it gives you some tips on how to fix this. But still, you notice that it tells you about the missing text but it doesn't tell anything about the missing are you pressed? Because it's not smart enough to understand that this is a interactive toggle button. For example, these links, some of the links are incorrect but it doesn't announce anything about it. Or these actions, this menu, it's not accessible but it also doesn't tell you that it's not accessible because it's dynamic. So the more dynamic your website is, the less effective the automated tools are. That's the reality. Another tool that I really like to use and I try to integrate on my projects is this one called, where is it? From Axe, axe-core react. I have it here installed and you will have it only for development. I'm realizing that I did this with React 17. But now I'm on 18. But basically this tool tells you on the runtime in the console when the HTML is invalid. For example, when you have like a list without allies or heading that is broken or something like that, I like to use this tool because you can integrate it on your pipelines, on your CI CD and it will tell you all the mistakes that your final HTML is. So you can give it a try as well. Besides that, it doesn't matter how many tools you use, there are some things that an automated tool will never catch. Let me just do a comment piece again, just to make sure. Next question. You think there is a place for Accessibility Overlays? Oh, don't ask me about Accessibility Overlays. I have this for you. Accessible Overlay. So for those who don't know about Accessible Overlays, is basically a type of widget that you install in your website and that widget claims that it makes your website more accessible. And the thing is it does not make your website more accessible. In fact, it might even make your website even more not accessible. And there is this page that explains what is an overlay, the type of overlays, tools at the consist of there and everything that is wrong with it. Okay. So if you want to learn more about it, go there. Don't be lazy. Fix the accessibility of your website. Create websites that are not broken by default. By default. And most of the time, fixing the accessibility is way, not most of the time, but always it's more effective than using an overlay tool. Okay? Next one. You have some tips and tricks on how to convince company management to let us work on accessibility improvements? Well, it's not an accessibility improvement. It's an accessible bug. That would be my answer. So tips and tricks, tell them, show them. You know, maybe they don't care. Honestly, I think that people don't care about accessibility because they do not know the impact that accessibility makes on people's lives. So most of times I share videos or videos from real people benefiting from accessible websites.

For example, let me think, for example there is this YouTube channel. Okay, let me search away from the screen. Which is a blind person using technical devices like iPhone and stuff like that. Oh, there you go. This one. So basically, it's a blind person that is not developer and they show how they use screen reader in their iPhone. And they have, she has a lot of videos about all the she uses, Mac, iPhone, iPad, and how it makes a huge difference in their day-to-day life. So maybe you can find some good content there to show your management team about this. Videos, it's showing them how it makes a difference. For example, there is a developer, a line developer called Leonie Watson, Watson, and she has plenty of videos on YouTube. She has one with Smashing Magazine. Super, super cool where she, it's this one. No, it's not this one. Yeah, it's this one, where she shows during one hour how she uses the web and it's amazing all the things that she finds that are broken or that could be improved quite easily and how it makes a difference in her life. So yeah, that's my tip. It's showing, you know, you need to show them how it makes a difference so they can have the empathy to understand more about it. What else? Oh, there is one thing about screen readers. You didn't use screen readers in this workshop, but you might think, oh, screen readers is so slow. It's kind of annoying because it takes a lot to describe everything and all the shortcuts and all of that. But I'm going to tell you, the people who use screen readers on their day-to-day life, they use it super, super, super fast. Like, actually, I was lucky enough to be with Leonie Watson in one workshop, and she was super fast. You know, open the computer, she was doing something and she was connecting to the internet even faster than some people that go there and try to connect to the internet of my previous company, doing all of the things, and I was, like, super amazed. And then during the workshop, someone shared this audio where it's like the normal velocity, the normal speed that someone with a screen reader uses the screen reader. It's not all the time, but if it's, you know, trivial things, screen reader, for someone who uses it on a daily basis. So get ready. Okay, that's enough, ten seconds. Okay, strange, okay. So there you go, the video again. Let me know if you hear it. Did you hear it? Yes, yes. Okay, by your faces I can tell that you hear it. So, yeah this is the normal speed, I think this is 5 times the normal speed, you know, and they can be super super fast, reading, accessing stuff, you know. We are Power Users with keyboards in your VS Code or any type of code editor, so imagine when you do it for everything plus a super fast voiceover on top of it or a screen reader on top of it. It's amazing, you know. Screen readers will not limit your abilities, it will, you know, it's just another super power to make it super fast in the web, okay. I can share this video as well. There you go on the discord. And I forgot to share the YouTube links, I will share them on the discord as well. There you go, all the links. Oops, I'm sorry with some extra, anyway. So yeah, that's my answer to auto-convince management. Show them, tell them, don't tell them, show them. That's the thing, okay. It's about human rights at the end of the day. Human rights at the end of the day, okay. More questions, okay, five minutes left. Some tips with the navigation and the approach to situational. We'll walk a few more. Okay, this one seems complex, let me skip it just to see if there is something else. Do you have any advice for dynamic loading list? Where you keep, where you keep, where you can't keep scrolling as it loads next list items. Okay, are you talking about infinite loading, if you are? So if you are talking about infinite loading, one thing that you could do is on your preferences have something that you desire about infinite loading. One thing that I could tell is like do not use ariel life in infinite loading, otherwise you are scrolling. And the same time it's announcing that, you know, 10 more items, 20 more items. I think that wouldn't be super useful. I don't have any resource right now, but if I ever will, I can share afterwards in the Discord channel, okay? Eminem is playing rap on that clip. What else? Can you share an experience about accessibility at work that's memorable? Yeah, when Leonie Watson went to my previous company and she gave a workshop, a presentation in a workshop. Again, she's a blind developer. It was amazing. I learned a lot from her. So, that was very memorable. Another memorable thing, oh, custom selects. They are a pain. They are really a pain. At some time, I wrote for CSS Tricks on how to create a custom select that is native and custom at the same time without reinventing the wheel. And it's a research. It's a guide. It's not really a tutorial. It's more research about custom selects. If you want to read more about how to keep a balance between a native and a custom select, maybe you'll have some fun here. What else? Four minutes left. Okay, that's the longest one. Give me a sec to read it. Okay, this one is about... This question is about clickable UI blocks that go to somewhere in a page, but they are just a link. Okay, so when you have a block of text and the entire text is clickable, one solution is to make the entire block a link. So let's give it an example. So like for example, this little cat here, imagine that the entire area here would be clickable. So the image is clickable, talk to you, and the link. So all of this is a link. If you put it as a link, as an anchor element, the screen reader will announce everything. The image, the alt of the image, the text, the link, the view. So that can be overwhelming, especially when you have complex cards. And there is an article from CSS Tricks called Balance Block Links, guys. Yeah, there you go. Block links is a search for a perfect solution. Where you have a link and all you make this accessible as much as you can. And there are multiple methods. And if I'm not mistaken, my favorite one is the last one. It's the last one, still the last one, yeah, the number four, where basically you have your card, your article, and you still just have one link at the end. And then you have some magic where when you click somewhere, anywhere in the article, it will open to a new page, okay? Something like, where is it? Here.

So if I click here somewhere, it looks like I'm clicking the link. But in fact, this is not the link. The link is just, you know, this part or this part. You can go deep into this article to know a little bit more. I'll put the link on this card. But please do not make a link around everything because then the entire card is a link and it's like for screen readers.

Okay. Okay, I think that's it from questions. One minute left. That's all I have for you today. I hope it was useful. Please, I think my last word for you is whenever you can, you can drop the mouse, use a keyboard and remember accessible, the web is awesome and everyone should access it and now you know how to make it better. That's all.