Hey everyone. Thank you so much for being here today. I'm Anad Ahmed, and for the next 30 minutes we are going to be talking about something that sounds complicated but actually beautifully simple, and that is it. Aria. We're going to try as much as possible to like, introduce what Aria concept is just like a guide for developers, share certain tips and, insights as to how best to understand Aria. And my goal is simple. In 30 minutes, you'll not only underst this. Stand what area really does, but also know when not to use it. So let's get started. Yes. What we'll be covering today in my talk we are gonna be covering the invisible problem. We are, we're gonna look at the invisible problem that makes some websites hard to use, and then we'll go over area fundamentals. What is it? What it is, and how it works. Then we'll unpack the three co concepts of Aria, which is the rows, properties, and state. And then we'll also talk about show we'll also show some coding. Examples, a few of them. And then we'll wrap up with the best practices, common mistakes, testing tools, and testing and tools, sorry. And then action plan. So by the end of this talk, you work away not just with the knowledge, but with the things that you can actually apply in your next project. Okay? Yeah, so the invisible problem, right? Accessibility issues are really visible actually. And that's one tricky part about it. There are when we have two pieces of code, right? Which literally does the same thing. They can look identical, but then they be behave completely different for someone using assistive technology. For example, the screen reader, right? An example of what we have here, what you can see here is, a very simple click me, right? Which is designed to be a button using the div element. It has a class of fancy button and unclick to do something right, but it actually looks like a button. Lets just put in that consent. It was written to look like a button, but then a screen reader would just see it and just say announce it has clickable. Click me, but there's no context, no role, no meaning. So why we see a nice button, someone using a screen reader gets almost like no useful information because it just says click me. It has no idea. A screen reader has no idea if it's actually a button. It doesn't know what happens when you just, when you click it, it just knows that there's something clickable there. Alright? And that's that's the gap between what we see and assistive technology understand, and that's the real problem Har helps to bridge. Okay going over to the next slide. Like I said earlier, what is Screen Reader one knows is like clickable click me and it's going to translate it as, oh, there's something you can click here called Click me. But I have no idea what it actually does. Or if it's even a button, like that's like the translation it's gonna have so why does it really matter to actually like, have a proper understanding of area? In actual, in general context accessibility itself is really about helping users gain proper understanding of how to like, use the elements we've, created on our website, for example. And it's just really about clarity, right? Regardless of how a user eased. Interfacing on interacting with our website content. And it's not just about trying to click check out a compliance checkbox or something, or trying to avoid a lawsuit. No, it's not just about that. It's about making sure that every. User, regardless of how they access our websites can understand and use what we build. So when we build accessibly, we're not just doing, we're not doing extra work. It's not an extra work. It's a us doing our job properly. Okay? And, because a product that's confusing or impossible to navigate is not complete. People would not be able to use it, right? So that's why it's really important for us to understand certain practices in accessibility. We should not see it as an extra work all or is it nice to have or I would just come, I would just add that feature to my website. No, it should not be seen as that. Okay. So that's the essence of the stock. Like just to introduce certain concepts that can help us bridge gaps. So now what I'll be talking about next is this H TM L as you can see from my slide is I wrote it, like at ML speak two languages. So that's like a kind of an analogy I want to go with in trying to explain the gap between a visual language, the visual content user sees and say for example, a semantic structure or semantic. Content that will help assistive technology properly interpret contents to users who are using assistive technology to interact with your site. Like I said, the visual language is, the visual language is, let me put it this way, it's what sighted users see, right? There, there could be like colors, the brand colors you have on your site, the layouts, the animation, the beautiful animation over effects and things like that have been added and the way things behave naturally in terms of how you could. Du those content on your website. And then the second language I want to go with is semantic language which is what most accessibility advocates always preach about. It should not just be about, how pretty your website is, but how well structured your website is. So the second language are we talking about is like the semantic language and it's what assistive technologies interpret? Say for example this is a button assistive technology. When it interfaces with a button, it's going to interpret it as a button, a well structured button when it interfaces with a proper. Heading level, say for instance a heading, this is a heading level one. It's gonna announce it as this is a heading level one, this is a navigation. Things like that. So that's like the second language, HTMO understand. Screen reader uses most often. Experiences, the semantic language. That's really what helps them in interacting and navigating properly with our website. And this actually, this, the crucial part is these two languages, I would say are. They need to say the same thing. They should not speak, they should not be different. They need to say the same thing so that regardless people would be able to understand the content. So when they don't say the same thing, but they look, when something looks like a button, say for example but doesn't say it's a button semantically for assistive technology that's when we can have an accessibility problem. Exists to make sure that those two languages always say the same thing. It's gives extra context to elements when playing HTML is not enough. It's how we had more, let me put it this way, semantic meaning when HML alone is not enough, and that's what area is not some, complicated framework. We need to like hard to make accessibility to help us, do some accessibility fixes. No, it's just like a. A, a way to just bridge the gap between, that's why I use the analogy of two languages, the visual and the semantic. So where HMO is not sufficient area. Can come in and then, had more meaning to ensure that the ish, the amount starts missed, makes sense for assistive technology users. So then let's like just I'm saying aria. Aria actually stands for, accessible rich internet application. Alright. Aria is is a set of attributes that tell assistive technology. That what something is what it does and what state it's in. That's where the three core concepts that. I mentioned in our agenda earlier comes in so we'll be touching base, we'll be touching on that later on in this talk. Just think of, I want you to think of area as translation notes for screen readers that when you like how do I want to put it? They're just. They're just notes that don't change how your code should look like, but they they're just like additional information, like I said earlier, for assistive technology to really understand. So when I say role, what is that role Is like defining what an element is, like having more definitions, what an element is, right. It's announces the names and descriptions to things like A label by things we'll be covering later on. And it also by communicates the status and say, for instance, is the accordion expanded or is it, or if is the button selected? Things like that. It's just like hiding more more. Notes for to help assistive technology to understand better what an element is. Like I said, think of Aria like a translation notes, aria attributes are, they just had more context to, what you have as your elements. So without translation notes, that's the first code. From what you're seeing on the screen. The first code is, it's designed to be a menu, right? And it has an unclick event. Now that is an element, a deep element without without aria, sorry. And the second one is with translational notes. That's harrier. In this case, we're talking we're trying to like, give a proper understanding of Aria by saying, okay, aria, similar to a translation. So when you see that, just know that's what I'm trying to explain. So the second line, the second div elements, which you see there, you can see that more things are being added there. So the purpose of those things are to define, a menu would be like a button, right? So the. The essence of hiding area to this, and this many element is to properly help assistive technology to understand that, oh, when it encounters this menu, it should behave as a button. That's the role we are defining to be. And then the we're giving it a label of, okay, open navigation, that's, what is it called? Like an open navigation menu. And so that's this is to help more, to add more context. So we are going into, like diving into the three core concepts that we can see at first here. So the first concept is the role. The role like defines what the element is, like I said earlier. So for example, like we showed in the earlier code, it defines the code below as a button, even though it's a D, right? We added the button into the code for it to be able to be like a button. So the next core concept is properties. Properties is like a set of characteristics that we've added for, elements to provide more details, like to describe it, say for instance you're trying to describe your. Your anti blue light glasses, you're going to have it described to someone, oh, it has a blue frame. It has a blue, lens when it's being set up. That kind of description, that more details you had to your elements. That's where the property concepts come in. So for example, in this code, the button is given. A property of area label and we are telling it that, oh, this is a closed dialogue. All right? And that's like the property we are giving it just to had more characteristics to help describe what that element is doing. Okay. The next one is the states. All right. The states kind of de defines what is currently happening with that element. So for example, it took, it could tell if a button is currently being selected or, that's, if the button is active or if, if it's press, kind of thing. So that's where we add the states and then we can use that attribute there, which is the area pressed to be true to, to tell that okay, the current state is what true. That's just like a very simple example of how the three con concepts play together. Okay. I, I've been mentioning, the example I've been given is okay, a div created to act like a button. The reason that was used mostly is because that is like a common mistake so many developers use. They try to use D to build everything when you can just actually go ahead to use semantic HTMO. So that's like the golden rule here that I'm trying to explain that no area is better. Is better than bad area. So the first thing first is to always go first with the native HTML. Always go ahead to before you try to use div to play around and customize setting elements. Try to see if those elements already exist in semantic HMR. Okay. Use buttons for buttons. Use navigation nerves for navigations use. Inputs for inputs. Don't try to design a D to look like an input field. All right? So that's like the first step to avoiding, future, accessibility problems because there's some instances where we might be trying to fix an issue an accessibility issue, but in the actual sense, we are even creating more accessibility issues. So the first golden rule is to use native HMO first and reach, only reach for Aria when there's no like semantic. Elements available and don't, like I said earlier, don't try to re employment, build in behaviors like, like I said, buttons, inputs and things like that. I. When you actually really need Aria, so use Aria components when HML alone is not enough to describe it. So for example, there's no actual HML elements to say. Carousels to, to create a carousel. Unlike the way we have a button that can be used to design a button, a semantic HMO button. That's the buttoning elements that can be used to like, build out a button. Not nothing like that exists for tabs or carousels or, models or navigation notifications and things like that. So this is where we try to build out some things with Ds and then style it into, style it for it to look like a model or what, it could be whatever elements we are trying to build in mind. Avoid area for standard controls or certain case cases, always test first. Those are also part of the things that we need to consider when. Actually deciding on when to use area. So the first thing first is to use area components when you don't have an alternative means to design an alternative semantic HML, to designing that element. So that's like a very brief introduction to how you can really actually know when to use area. A few code examples. This is a, this is an example of, without Aria. So as we can see here, the div element is created to display a notification message saying message sent successfully. But in the actual sense, no announcement will be made if an an assistive technology is trying to like, or. If an assistive technology comes in contact with this element on a website there's no way. For. For a user without disability, they'll be able to like, okay, see that. Okay, that's the message, a message successfully sent. But a user using this assistive technology, like a screen reader would, like I said, would definitely get no announcement. So now looking at the second version we've had it like three. The three area attributes we talked about earlier, the role, the description, and the the states, right? Here we had the role to be a notification, right? To give that, to. Status sorry, that status notification that this is a status. So we're trying to tell we're trying to de define the role of this notification that we're building to be a status. All right, so the next one is the area life. So the area life is another attribute to that. We used to announced sweat. Was subtly telling that this should be announced pro politely. So that's like a characteristics we are trying to like, define for that notification. And then the last one is just just tell, okay, message send successfully. So that's like the actual, content of that notification. And these two attributes that we've added would completely like change the experience of for an assistive technology. Like it's going to give more content. Now the message is gonna appear, this screen reader automatically analysis to be like a message sent successfully compared to the first version that we have on the left side of the screen. For, users, any for users, say for example, a user without a visual impairment can read the first one to be like message sent successfully, but then it's not helpful in any way if a user using the assistive technology cannot does not get any feedback. No response. No, sorry. No announcement. So this is why, this is what we are trying to explain earlier on that those simple changes can really make a huge difference in how our users, our diver, diverse range of users get to experience, our web content and how they're built. So one line of code can, really make your heart work for everyone, so for that's for the. Notification and then we have for our models. That's another example that I have today to like use to further explain this introduction to area. And there's always one problem with models. The problem is that when a model open, a screen reader user would not like. Often realize that, okay, that model has been opened or probably what the model is for or how to close it. All right? And visually. When we talk about the visual language, it's there. Okay. It's opened, but then on, for, on the screen reader side, it'll not see it. There's a, there's an X to close it, but then the screen reader will not also see it if it's not properly announced correctly or the rules are not giving. They're not like added or not even, or. Or they're not added, or they're added and not added correctly. So that's another case, right? The solution here is to like, add a couple of area attributes. So the first one is here we are given a model here. Role of a dialogue. So that's like the role we are defining so that whenever a screen reader encounters that element, you don't understand that, oh, this is a mod dialogue. Okay. And then the next one is the area labeled by, which is, which falls under the properties concept. So this is the, like the characteristics we're trying to define for it, and we're saying that, oh, the aerial labeled by points to the heading the selves as the. Dialogue title. So we are going to be pointing like that property to the heading. Alright, so then the, another description we're giving it is the ariel described by, so those are like. Pretty much setting quick references. At the end of this talk, I'm going to show some quick references that you can always like, follow through to help you further understand that, okay, yes, this is what this is. And there also a couple of more resources that I'm gonna be sharing so that I can have more, context to aerial elements. For the area described by Yeah, we are saying that. Okay. This p elements would serve as the description for our, for our model, so that when it's announced, the screen reader knows, okay, this is what this model is meant for. And, with the title the screen reader, user can, get a preview idea or, a short idea of, okay. What this model is about. And that will be like, okay, confirm the needs. So when it announces it as confirm, delete model the screen reader user knows and it's prepared that, okay, this is for me to delete something. Alright. And then it gives that more context to description of the. Dialogue to be, okay, are you sure you want to delete this item? So that's really helpful. Just those two descriptions is adding more context to help, improve the experience of a screen reader user. And then a couple of other elements there is just cancel and then delete. So if the user is still gonna go ahead to delete, they know like how to move their, cause how to move their keyboard around to help them navigate to the delete section if they still want to delete or just go back. So just those few things helps, compared to not even hiding any of those things at all. And just having your div and then. H two and then a P tag and then the two buttons and style beautifully in the modal box. It's cute visually, but then functionally it does not help, screen reader users. Yeah. That's like the purpose. And then we are, trying to provide more context for screen reader as like I said, so the common mistake, I think I mentioned one common mistake earlier, but so many developers aside from okay. I think I mentioned the common mistake the other time I remember now the common mistake I mentioned was using Ds to create buttons and we've already talked about how not to do that, so we should always use like semantic, some of us. So that's great. Then another common mistakes is adding Harry to everything. Every single element. And that's not great because when you add Aria or use Aria when you're not supposed to, like I said earlier, that's like adding more accessibility problems, like creating more accessibility problems rather than fixing those problems. Another one is adding I interactive elements. Like I sometimes when I like click on the, I inspect of certain website, I see area eating true and I'm like, no, that's like a common, that's one mistake that people also make. Developers not. I lo like forgetting keyboard support. Aria usually doesn't have keyboard functionality. So we still need things like, our on click events and keyboard atlas and things like that to help, with keyboard functionality. So we should not think Aria is going to like, have those things for us automatically. They're not, they don't work that way. We already explain like. Why, what area does just adding more context, right? So we should have that notes like adding more context to help screen reader understand certain elements that are not built with semantic H demo. So that's like the best way to break it down. Also, I think I mentioned this conflicting rules or invalid states. Maybe for a button we are. Assigning is a role of a dialogue, right? That's like creating an accessibility problem. Or, giving a dialogue role of a bot team. There are other different rules that we can always like reference on the MDN documentation or altering practices yeah. By Y area. Yeah. Like I said, those common mistakes, yes, they're, they have solutions. So the fix will be to always use the semantic H number and then we test with our keyboards to ensure that, users can also can, navigate with a keyboard without the mouse and then test with screen without, to ensure that okay, these things are announcing correctly. So there are tools and tests tools and technologies that we can use to do those testing. Like I put here, we should do the keyboard test first. Navigate without your mouse and ensure that the focus is visible and logical, right? Yeah, that's just unplugging your mouse and try to navigate with your keyboard. Can you navigate everything? Can you activate it? Yeah. And then are they focus around your elements, like your buttons? Does they have enough focus that that will help, assistive technology users as well? Also there are screen readers you can always download NVDA, you can download on Windows, but Mark itself comes with a voiceover, so you don't need to download those. Just listen, just use this screen reader tools to help you listen to how your page is being announced or described. And then there are also automated tools that you can use to check where check for errors on your site. Maybe just to check and spot if you can find area errors or no area errors. And it could be any other errors, right? So you shouldn't wear, you're testing your site. Don't just test for the area, okay? Just go through everything and ensure that everything works. Okay. So yeah, baby steps. Slow. Like I used to hear, slow progress is better than no progress at all. So it's not like a one day thing to get it all right all at once. It's tiny changes that could yield remarkable results that could, provide impactful changes to help, improve the experiences of our users, right? So automated tools like, ask step tools, wave a Lighthouse could help spot those issues and then you can look at how to fix them and, try to retest again manually and see if everything works correctly. I was talking about quick references. There are a couple of roles that. These are like common area attributes that you mostly use all the time buttons navigations, dialogue, alert status, remember, don't go first using a div to create a button. Okay? Always go for the semantic way of creating a button. Okay? That's like a quick reference for roles, a quick reference for labels, for, properties, adding properties like, we had the A built by in one of our examples. And then we use our IDs to target them. I think I, we have that in one of our examples. The area described by, like I said, we had in our example, a mod example where we had a Peter to provide more context, more description. So we use the area described by and target targeted. It's using the ID and added that inside of our, that's that a quick reference for state. Okay. Is it an expanded one? Is it open? Do you get it? Is it closed? Using are expanded setting to true or false or are selected certainly to true or false. These are, ways, these are quick references, like the Area Aid true or false that we mentioned for interactive elements. That is so that's why I said that it's a common mistake because there's so many elements that developers can, would just go ahead to put Area Aid to be true. Just so that it's to fix to fix maybe an accessibility issue they're trying to encounter something like that. That, that area, ed didn't mostly say, oh, should query reader ignore it. It should always be used correctly and right. This is the, another one quick reference for live regions. That's all still on the properties. The area live should be announced. It's politely or ative, like announce immediately or announce when I do just to provide more characteristics to that element. We're trying to create where plain HTMO is not sufficient. Alright so when we are trying to do these steps, this, baby steps, we're learning, we're growing, we are, trying to, as much as possible ensure that. Our websites are content accessible. We also, it's also very important to build an accessible workflow. We should not always make accessibility to be something that should be considered when our site has launched and our users are complaining that, oh, they cannot access certain things in our website. No, it should always built, it should always be built from the very beginning. Start semantic, then hands with Aria. When you want to build elements that plain HCMO does not suffice. Then also adding, accessibility checkers to to accessibility checks, sorry, to our pool request should also automate certain things. And why you automate is also important to also test mal d. Just like going through checking manually to see if everything announces correctly. And it's also important to like, include accessibility testing into things like our design system. So when all of this is part of our process, it stops looking like an extra work. Oh, it's an extra work. I can't do that, kind of thing. So yeah, so that's why it's really important. So another thing is another action plan, I would say aside from building. Accessibility into our workflow is that we should keep learning. We should read why area practices, authoring practices about area, to learn more and build more. Nobody knows it all. Quick insights, knowledge about certain things is really helpful than not knowing at all. So it's very important as professionals, as developers, we should learn about this. Best practices. We should also audit and we should test our keyboard flow. We should run, ask step tools. We should, fix stuff with, I impact issues like, issues that you know, that are really impacting our users. We should start with those. We should also like sustain, keep. Accessibility into our PR and review processes. It's just like those small steps that will really make a huge impact. So my key takeaway, the key takeaways here is what I want you to really remember is that area should not be like, or, checklist or, things like that. It's about respect. It's about respecting that people use the web in different ways and it's about ensuring that. What you build is usable by everyone. Okay. And it's not just the web has we personally experienced. It's like it's about building for the real diverse users. Alright? Every area attribute you write is an act of inclusion. Every area attribute you write is an act of inclusion. Those done the right way. Okay? So it has to be done the right way for you to write something that's an act of inclusion. That's the art of accessibility, making sure that every user's feel what included. Yeah that's it. And then we have a couple of resources, like I said, that would be added to the end of this co this talk. The Y area altering best practices. You can always visit that to see a list of more area properties road. Yeah, states that you can, learn to use. We also have the MDN area documentation is also a very detailed documentation that explains, more area concepts. We also have the web aim article on area, like I think web aim had a very detailed at school and area, which I've included here. And then I also linked to a couple of resources sorry, a couple of tools that was mentioned earlier, which is like the Ask Dev two, the NVDA and the Wave. Okay. That's it for me. If you have any questions, just send it to me. I'll be more than willing to answer to the best way I can. Thank you so much for listening.