 Firstly, I'd like to wish you all a very warm good afternoon and would like to say that it's indeed a matter of immense pleasure to be here and miss you all. My name is Deepika and I'm working as an accessibility consultant at DQ based in Hyderabad. Today I'm going to speak on the topic building accessible custom widgets using ARIA. But before we dive into ARIA, let's first understand the term accessibility. So in layman terms accessibility is ability to access. It's about making things more useful, more understandable, more accessible to the people with different disabilities. So often when we speak about accessibility, people are just laser focused on just compliance, guidelines, and principles, best practices, laws. And also there's a misconception that accessibility is just for people who are differently abled. Well, that's really not what accessibility is all about. It's actually way beyond that. A fifth of the population on this planet has some kind of disability and 8.5 percentage of people are aging. So to cope up with these numbers, I think we should be addressing accessibility. If we are not, then we are leaving tons of people digitally impaired. Now, you must be wondering that why this woman is speaking on accessibility in a JSCon. Yeah, it's a valid question. I personally believe that no one person is responsible for creating an application or a content. I think it's a team effort and so is accessibility. Every person in the team has some role to play, whether it's a developer or a tester or anyone, designer. So I think everyone has some role to play. And if we are addressing accessibility, we have to make sure that it's on a priority while we are working. Now, people with different disabilities actually use different types of assistive technologies like screen readers, screen magnifiers, voice recognition tools to access the web content. In the next slide, we're going to see how a blind person or a partially blind person access the web content using a screen reader and VDA. If you're still awake out there and you haven't given up on this, you must have noticed that the screen reader was not just reading the web content, but it was also identifying the semantics of the page like headings, slings, like the semantic markup and also the landmarks of the page like header, footer, main content. Well, this wasn't the case until accessibility APIs came into picture. In late 90s, accessibility APIs were introduced as a more reliable way to pass on information to the users. And the first thing it enabled was semantic navigation and landmark navigation. And this, I would say, was one drastic change that has overturned the whole screen reader user experience. Now, the screen reader is able to navigate through the page using semantics. Like if they're interested in the headings, they can navigate with the headings. And also with different screen readers, we have different shortcut keys available using which they can directly navigate through the different semantics and landmarks. Now, on the screen, you can see we have accessibility layer. You can call it a stack. On the left side, we have web application. On the right side, we have assistive technologies like the one which I've seen just now. And accessibility tree actually works as a mediator between both of them. It takes a bunch of information from web application and pass it on to the assistive technologies. Now, you got the crux of how it works. So it's a common knowledge that whenever we load a content on the web, a browser actually creates a DOM. It's a document object model. It's a hierarchical structure of information that we can interact with. We can manipulate using scripting. But the lesser known factors, browser also creates an accessibility tree. And we can call it a replica of the DOM. It takes a bunch of information from the DOM and it added to the accessibility tree. But this time, the information is more dedicated to and specifically to be used by assistive technologies. And some important information includes roles of the element, properties, states, all those things. So we got all the information in bits and pieces here. We got accessibility APIs. We got assistive technologies that can make use of it. But what do we do with all these things as a developer? How can we use it? Firstly, using JavaScript, unfortunately, we cannot interact with the accessibility tree. However, what we can do is we can use ARIA. So ARIA is accessible rich internet application. It's a specification from W3C currently in version one. We are already working on 1.1 and looking forward to version two. ARIA is basically used whenever you want to create some custom control or a custom widget. Like you're going out of semantics and you're customizing an element. Then you're using ARIA. It has a set of properties, attributes that you can use in your code and you can build and create something which is much more usable to the end user. But obviously you have to use it with a little bit of caution, though, and why the reason I'll tell you later. So now we know what is accessibility tree. Now we know what are the informations available. So we are going to go through all those information one by one. Let's take the role first. And this is the most crucial information which is present in the accessibility tree for the assistive technologies. Role of an element tells the browser all the assistive technologies what kind of element is that or what type of element is that. Usually when we are using native HTML semantic markup, they have implicit roles like role of a button or role of a link or images. But when we are creating something customized, like some customized elements, we are using diverse pan to create them, then we have to add explicit roles to them. So if we see we have two parallel examples here on the left side, if I add type to checkbox, this will become a checkbox. So if I want to mimic the same thing and I want to create a custom checkbox, then I'll add role of a checkbox. So now the screen reader will identify this element as a role of a checkbox. Usually like span and divs are considered as semantically neutral, which means they don't have any role. And of course they are not actionable elements. So we have to make a lot of changes to make it accessibility compliant. Now state this another information, very important information which is present in accessibility tree for the screen reader users. Now visually we can perceive this information that some checkboxes check or radio button is selected currently, but for a blind person or for a person who cannot see like see completely see the screen. For them we need to provide the same information in some way so that it will be announced to the screen reader users. They would know the state of the element. So if we use native semantic HTML markup, we'll just use check and that's it. I mean the browser is very intelligent enough to understand that. But if you're using a custom control that we have to use aria check to true. Now aria checked to true, we'll use for the checkbox, which is currently in selected state or checked state. And there is an important point to note here that whenever we are using native HTML semantic markup, then we don't have to toggle these values like browser automatically do it for you. You don't have to make much efforts in making things accessible. They are pretty accessible on their own. But if you're using custom code and you're using aria property especially, then you have to toggle the value of aria check to true or false based on the current state of the element. And this we can achieve using scripting. So we have actually a long list of properties and attributes that are present in aria. However, name is one of the most important things. Name actually differentiate an element from a group of elements of a similar type on the same page. Now on the left side, we have a very regular method of providing a name to any element. We have used input and label and we have associated the name with the input field using foreign ID. Now if we want to mimic the same thing and we want to achieve it, then it's very similar to foreign ID association. We are using aria labeled by and in a value we are providing reference ID of the label or the accessible name of it. Now I think we are quite familiar with aria and what importance it has in accessibility. So I think we are good to start with like building a custom widget now. So we'll start with simple HTML skeleton. Our intent is to build a tab widget which is quite fairly accessible. So we are going to provide the list of like the tabs, individual tabs in a ULLI and the tab panels in div. Now if you provide some CSS or JavaScript to this element, now this might work fine with the mouse. But let's see what happens if we try to access this widget using a mouse and with screen reader on. So I think this was working just fine. And this might look very simple but trust me guys, this has huge number of accessibility issues that we are going to find out over the next few slides. Now we are trying to access the same widget, same tab widget using keyboard and screen reader on. Let's see what happens. Well, nothing at all. We were not even able to enter into the widget and if we are not able to get to the widget, that means we cannot interact with it. That means we don't know if something is there on the page or not. So everything pretty much stops there. So how can we rectify all this? How can we build a custom widget which is much more accessible? What are the properties that we can incorporate? What are the attributes that we can add in this? So we'll start with simple roles. Let's start with role of a tab. Role of a tab as the name says, we'll apply it to individual tabs, individual tab controls. Now, tab list we'll apply to the UL which works as a container for the tabs. Role of a tab panel we'll provide to individual tab panels or the content which appears on activating any tab. So we have the code here. Now we'll see how do we apply these things. So firstly, role tab list to the UL or the container. Role tab to individual tabs. Role tab panel to the content or the tab panel content. Next, there are certain other attributes. So I was talking about the states and the name, the label. So all those attributes also we have to add here. Firstly, we'll see tab index zero which will put the tab panel in the tab sequence. Tab index minus one, ARIA selected, ARIA controls. So what are all those things we don't know? Okay, we're gonna see this one by one. Firstly, as we were accessing this widget using keyboard, so we have noticed one problem there. We were not able to enter to the widget or to reach to the widget. So what do we do to provide focus to the widget? I think you all are familiar with this. We provide tab index of zero. Tab index of zero is the most natural way of providing a tab focus or keyboard focus to any element. It keeps the element in the natural tab order of the page based on elements location in the DOM. And if you want to provide, if you want to take focus from an actionable element or any element, then you'll provide tab index of minus one. So at a time, like from our design, design pattern, if you follow our design pattern, then we'll provide tab index of zero to only one element or one tab, which means only one tab will receive focus at a time and we can navigate within the tabs using arrow keys and tab index of minus one to all the other tabs. Next, suppose you are a cited keyboard user. You are just navigating through the page, like through all the actionable elements of the page using tab keys. So you'll just keep on tabbing and tabbing and tabbing and you don't know where you are because you don't have any focus indicator. So, of course, if you don't have any focus indicator, you won't know where is your current location on the page right now. So for that, we have a small code snippet here. We can provide focus indicator with this and usually user agents provide their default focus indicator for all the actionable elements. But if it's not there, we have to make sure that it's available because it's one of the checkpoints that we look for whenever we test any page for compliance. Next, we were talking about the state of the element. So, usually we can perceive which tab is currently selected. But if we want to provide the same state information to the screen reader user or to the user who cannot see the page, then we'll add an attribute, aria-selected to true and aria-selected to false. So this is very similar to aria check that we have seen earlier. aria-selected is basically we are going to add to a tab which is currently in selected state or expanded state. And one more thing, as we have seen in the checkbox example, we have to toggle this value to true and false based on the current state of the element. Now, we have aria controls. So, usually we know which tab panel or the tab contents belongs to which tab. Like tab one belongs to, okay, this content belongs to tab one, this content belongs to tab two. But how do we build this relationship between the tab and the tab panel? Well, using aria controls, we can do that. We can provide aria controls to the individual tabs and as a value, we can provide a reference ID of the content it's controlling. And also, it's very important at some time because with some screen readers, generally, when you activate a tab or you select a tab and the corresponding tab panel will displayed, then the screen reader will assist you with some shortcut keys that you can use and you can directly navigate to the widget. So I think by now, you must have understood the importance of keyboard and accessibility. So it's very important that we start listening, we should start listening to the keyboard events along with the mouse events as well. And we have to make sure that whatever functionality we can achieve with the mouse, it's available for keyboards as well, otherwise that will not be accessible. Like it will not be completely accessible for everyone because there are some people who are using just keyboard to navigate through the page. They are not using mouse like the screen reader uses, for example. So we have to make sure that all the functionality that is available by mouse is available by keyboard as well. And for that, we have to make sure that we use a device independent event handlers, which means the mouse event handlers, event listeners, which has their corresponding keyboard counterparts. Next is the keyboard navigation. So actually, for different widgets like tree or menu or a dialogue, we have different design patterns and also different keyboard navigation patterns. But if we'll talk specifically about the tab widget, which we have seen right now, so the one which we are going to follow is we're going to put keyboard focus on just one tab, and then we're going to navigate within the tabs using arrow keys. And if you want to activate any tab or select any tab, you can press enter or space key. And on next tab, you will be on the control or the tab panel of that element. So this is a very simple function, which does exactly the same what I have said right now. And for this, we have to grab the key codes of all those keys, like the arrow keys and tab key, and we have to put in this function. And this will work. Usually when we use native semantic markup, a browser provides their compatibility for a space or enter key. But if it's not, then we have to grab the key codes and we have to mimic the same functionality. Okay, now we're going to bind everything together using this simple function. We are going to toggle the value of aria selected to true or false based on the element state. We're going to toggle the value of tab index to zero and one based on the like the focus state of the element. We're going to toggle the value of aria controls. And also are you hidden? So are you hidden? I know I haven't explained it here. But are you hidden? Basically, are you hidden to true? We provide to the tab panels, which are currently in hidden state. Of course, if we select one tab, only single tab panel will be displayed at a time. So the one which is available, like which is visually available for the user for that are you hidden will be false. And for rest of the tab panels, it will be already hidden to true. Now we are going to witness a more accessible version of a tab panel that we have seen earlier. This has all the properties, all the attributes, which we have gone through so far. And as we have put so much time and effort in this, I'd like to request you all to pay a bit more attention to notice what difference it actually makes to the screen reader users. So if you have noticed, the screen reader is announcing the role of the element tab, tab panel, and it's announcing the state of the element selected. And it's announcing the name of the element, like nil's form on Agnes Orville joke. So this is a very basic one. This is a very simple example. So I've taken this up. And if you guys are not familiar with aria, then now I think I'm hoping that you are now quite familiar with it. And I'm hoping that you would like in some way incorporate accessibility in your not just in your work life, but also in your day to day life, because it really helps some people to be more like some things to be more useful to more people. And also we have diversified group of people. So we need to we should we should make sure that our things are more useful and more accessible to everyone. Lastly, I'd like to conclude my talk by saying that use aria, but be very cautious because yeah, it can work like a charm. But sometimes if you tend to overuse it or misuse aria, believe me, it has all these trends, it has all the powers to make things even more worse for the end user. So that's all from my side. We have some resources here. You can go through the accessible tab widget examples. You can go through aria versions, which I mentioned, you can go through the cheat sheet, accessibility web content accessibility guidelines. And if you have any questions, please go ahead. Yeah, sure. Hey, thank you for covering this topic here. I'm very happy about it. I wanted to understand what's the library ecosystem for popular JavaScript frameworks with aria? Well, JavaScript as I said, aria like we cannot interact with aria, but using JavaScript, we can toggle the values or we can add some value in the accessibility tree, we can delete some value from accessibility tree, but generally, it's not very much compatible with it. What I needed to understand was is there a react library for As of now, no, it's a part of the scope. Okay. Thank you. Thank you. Hi. Sorry, you're not audible. Hello. Yeah, yeah. So I think my initial question already got answered. So I really want to ask this is some way we can do something in react or a particular library or framework or some boiler plates. Like, you know, I've never got a chance to work on the accessibility thing, but if we have to start on things, we have to start by saying text one by one or something like we can use it or some take the advantage of best practices. Well, yeah. Firstly, if you got the like idea of aria and idea of first of all accessibility, then it's like very much thankful to everyone. And at code level, yeah, you can add aria properties. But again, like you need to know where to add it and you need the exact like you need the exact know the exact usage of it. Otherwise, you will, you will tend to misuse aria and that will be like blunder. But at code level, as I said, like as I answered before, using JavaScript, we can just add the values, we can just remove the values, we cannot interact with it as of now. But I think I might be wrong, but as per my knowledge, I think we cannot interact as of now. We can just, you know, manipulate it and we can just override the information which is already present there in the accessibility tree. However, I think it's a part of the scope. So just one more question. Yeah. So how much is it like reasonable for the lighthouse scores or matrices, proper comments, like in terms of SCO and all those things? So how much is it relevant? If we do run a lighthouse score of any particular application or something, so there's accessibility. Yeah. Yeah. Design for that. How much is it relatable to that? Actually, the compatibility of accessibility differs from application to application. And also the screen readers compatibility, if I would say like to be more precise, I think you can use accessibility in your applications like as much as you want. But like, I think what was your question? Just wanted to ask like, mainly how much is actually, as per the application application, but yeah, how much is it relevant to lighthouse like in terms of SCO? Yeah, I think I answered it. Like the compatibility of accessibility changes with each and every application. And obviously, we are not using ARIA in everything, it's just still evolving. So let's see how much we can do with it. Thank you. Hi. Yeah, you're audible. I can hear you. I've never used this. Okay. Can you interact? You can interact, like you just spoke about interaction with the website. Yeah. Two, three ways. Yeah, keyboards. Yes. Yeah. So can you interact? So these things are not in-built in screen readers that we have to, like we have to, like for different browsers, we have different screen reader compatibility. And we have to make sure that whatever functionality we are achieving with different screen readers, it is available in the form of code somewhere. We have to do it, right? So if we are achieving something with like, as I said, like not only the mouse users, not only the keyboard user, there are other assistive technologies as well, which are taking part in this. So we have to make sure that we are coding something or we are implementing that in the code level to make it compatible with your browser or your application. Yeah. No, no, that's okay. The screen reader will just read the content which is there, which is already available. It cannot perform any action. Not active. If you navigate with the tab keys, tab keys is obviously, we use it to navigate to the focusable elements. So if you want to read the static elements, we have arrow key navigation. So we have different shortcut keys available with different screen readers. So if you navigate with the arrow keys, it will read the static content on the page as well. So screen reader will do no function for you. It will just read the page content and that's it. Yeah, voice recognition tools now. Yeah. Voice recognition tools like for someone who is motor disabled who cannot use keyboard or who cannot use mouse. For them, they can just command to the computer or they can, they have some tools which I just mentioned. So they can voice assistant tools like also Alexa is a good example of that. So, and also like we have this, in WhatsApp, we have this voice recording option, right? So there also, we don't have to type, we just press on that button and we can record that. So there are various methods that we can incorporate accessibility in and we can also address different types of disabilities. Actually, it's a huge spectrum in accessibility. So we have different tools like all of them I cannot cover here. So that, that also you can go through all those links. Yeah. Yeah, but like as I said, it's just an interface. You can use it anywhere, but the only point is it should be compatible with your screen readers firstly and the screen reader should be able to identify and expose those information which we are adding through ARIA. So that is the main point and that we have to try and check. Like, we cannot generalize that it's available for them. It's not available for this kind of people. Yeah. Yeah, that's, that's not a very, you know, highlighted thing and something which people actually focus a lot. But now I think as you all are aware of, you must, must keep this thing in mind as you are all developers and you are also responsible for building more accessible applications. Okay, one more last one. Hi Deepika, thank you for this presentation. So I think from what I heard from the questions is there are a lot of misunderstanding about accessibility ARIA and SEO practices and whether there is a pattern available already for frameworks and all. So I think it's a matter of, you know, exploration. So there are patterns and libraries available for each and every framework out there. You just need to find it, the right tool for it. For accessibility related things, you can just search and get up something like, you know, Ali A11y, awesome Ali, there is something called awesome Ali, where you get a list of all the libraries and stuff like that. And one more thing I would suggest is that, so since Deepika is from DQ, so DQ is providing accessibility audit for your products. So you can check with DQ for the accessibility audits. So we in Freshworks R company recently made an accessibility audit for our products and we found out a lot of accessibility bugs. And accessibility is not just for, you know, B2B or B2E, it's for everyone. It's not just, you know, if you are giving products to a particular segment of users, so it doesn't need to be like those segment of users are not, you know, don't have any accessibility impairments. So they can have anybody. As Deepika mentioned, 5% of the world population is differently able to people. So it doesn't matter where they come from. Okay. Thank you. Thank you. Thank you.