 Okay. Hello everyone. So I welcome you all to the HelloA11Y August Meetup. This is me, Tanisha Sabarwal and I will be the host for the day. So we're sort of experimenting with more regular meetup. So this is one where we try to bring in more of workshops, more meetups and all of that. So if you have any suggestion for us in the coming month that we should be doing a meetup particular to something, you can just let us know so that we can help give back to the community better. You can maybe DM us on our Twitter handles or DM any of the organizers, Manjula, Aditya or even me. So without further ado, I think we should get started. So the speaker of the day is Anuradha. She is a front-end developer and she works as a front-end consultant and she is an accessibility advocate. She recently became GDE, which is the Google Developer Expert for Web Technologies. So congratulations on that. And we're very glad to have you here. Today, she'll be speaking about creating accessible React applications. And personally, I'm very excited for the talk because I use React a lot. A lot of front-end developers' favorite thing is React. And even if you don't know React, I think this talk will help you broaden your horizon on front-end accessibility in front-end and web technologies. So over to you, Anuradha. We are all excited to have you here. Thanks. Thanks a lot, Anisha and all the organizers. I'm really excited to be speaking at this event. So, yeah. Hi, everyone. Welcome you all here. So let me share the screen once. And let me know once you can see the screen. Yeah, we can see it. Awesome. So, yeah. So, hi, everyone. Again, my name is Anuradha Kumari. And today, I will be talking about creating accessible React applications. So before we start, Tanisha already gave a nice introduction. So, yeah, I think I will skip most of this. But if you would like to reach out to me to discuss any technical thing or anything related to accessibility, you can reach out to me on LinkedIn at Anuradha15 or on Twitter. I'm on Twitter by idmiracle underscore 404. So the topics which we are going to cover today are I will start with introduction of accessibility and what is its importance. And then we will first see how to test for accessibility so that we know what are the issues and then we will see how to fix those using the code. And I will also share some useful tools and extensions, resources, which will help you to get started with it and discover more on accessibility front. Let's get started. So accessibility. The first question always comes at what exactly is accessibility? Accessibility, it also is a neuro name called A11y where 11 refers to the number of letters between A and Y. So it is accessibility means making the resources and services usable by everyone regardless of their ability or disability. Why should we care about accessibility? Like why are we talking about it? Because whenever we build, we build it for the users. So whatever we are making, our products, application, everything we are building for the users and we do not know what our users could be going through. So they could have certain disability or they might be using different type of technologies or different type of tools to use our application. So there are things like assistive technologies like keyboards, screen readers, switches and so on. So they could be using our applications in a different way and not just like using mouse and so on. So is our content which we are creating compatible to all those things? So is it accessible to all different types of technologies? Also the third and the most important thing which I believe is we need to care about accessibility because it is us who is making the web inaccessible. So often we do not follow the right coding practices. We end up creating a very bad markup or we end up doing something which was not supposed to do in that way and that makes the things inaccessible. We will see some of the examples today so that you will know what I mean by that. As per WHO, World Health Organization, around 15% of world population live with some form of disability. Now 15% translates to around 1 million people in the world. It's a lot. There are huge number of users and we should be caring for each and everyone for them. And we must be making things accessible for all of them. There are different types of disabilities when we talk about it. So there could be a visual, auditory, motor or cognitive. So also they can be categorized into multiple ways like they could be permanent, temporary or they could be situational. So if we talk about visual, so if someone is born blind or that could be a permanent disability, however someone who might have any infection in their eyes or maybe they've developed some cataract or something, that could be a temporary disability. Then let's say someone is trying to read something or access something in a very bright light. So that bright light might be a situational disability like in that bright light, you cannot see multiple things properly on your screen. So every one of us, it says that every one of us, it's true that there are around 15% of people who are have some form of disability, but 100% of us might have situational disability at one or the other point of time. So it's really important because we don't know who will need those accessibility features throughout their life. And since there are lots of different types of users, so there are different types of ways in which they can access the web. So these are also called assisted technologies. So for example, there are screen readers, keyboards, switch magnifiers, they are braille and a lot more different types of technologies which users end so that they can access the web properly. Now, when we talk about accessibility, accessibility helps everyone. It also helps the people who are having any technical issues. So like someone who is on a smaller, who is on a slower connection or who are using maybe some older operating system and so on, then there could be people who are using our content on small devices, phones or tablets. So by making things accessible and actually by making things responsive, we also take care that these are properly accessed by users who are using it on different device sizes. Then situational disability which we just covered in disability section. So there could be different types of situation in which you might need to use accessibility features. For example, again, if you are trying to hear or like maybe hear some audio or some video in a very noisy surrounding. So if it has some subtitles or some closed captions, then it will be really easy for you to understand the content. Also, there are something called a progressive disability. So a person might have everything fine to their but as the age proceeds, there might be some hearing disability or some side disability, motor disability and so on. So people might need at different age points or different accessibility features to be able to drive the web properly. So for accessibility, there are official guidelines and principles and those are called WCAG. So WCAG means web content accessibility guidelines. They are all divided into four broad categories which are called four principles. They are acronyms as four. So how do we see this? So whenever we create something, we must think that whatever I'm creating, does it really adhere to these four principles? So what is it? Here, P means perceivable. It means that whatever content we are creating, that must be, that can be perceived by the user in any form of their senses. So if a person can see, they can see and perceive that content. If they cannot see, they can maybe hear or they can touch and then understand what is the content. Operable. Now that the user has perceived that what it is. So let's take a very example of a form maybe. So let's say I have a button on a form. So I perceive that, okay, this is a button now as a user or whatever I must be using. So I might be using a mouse or a keyboard or a switch. I should be able to operate on it. So I should be able to operate that button. The third thing is understandable. So user must be able to understand what they have to do. Like if there are any action or any content, the user must be able to understand what it is and what action they have to take. So like if there is a button, then they must understand that, okay, what this button does. Then robust. So robust means there are multiple types of user reasons, browsers and new assistive technologies which might be coming in. So whatever we are creating that must be compatible to all of these so that users might be using any one of those, but they still are able to access the application properly. There is this website, so w3.org, it is official website and it contains all the information. So there is this link where it tells about Vakag and what exactly is meant by this poor. It's a very nice one which gives a very high level idea of how you can realize the poor. So you can go through it and understand this is very nice website. Okay, so we just saw a little bit of introduction and importance of accessibility. Let's start by testing from accessibility perspective. So whenever we are creating something, how do we know it's accessible or not? For that, we will have to test it, right? So let's first start with testing. The first and most basic form of testing which I feel is just using your keyboard to test the website or your application. So unplug your mouse and just use your website with your keyboard. So I have an example here. So yeah, in India, we have this flipkart.com which is an e-commerce website. I took this as example because there are lots of accessibility issues here. So we will get to know what exactly inaccessible things look like. So for example, and throughout this session, I'm going to focus more on a keyboard plus screen reader. The users who use keyboard and screen readers to navigate through the web because there are different combinations and we cannot get it for all in one session. So let's say I try to use my keyboard for it, okay? So for keyboard users, they use tab and or shift tab to go through the interactive elements. So interactive elements like buttons, form elements, anchor tabs, etc. So I will try to use tab to move forward to all the interactive element and you can use shift tab to go backward to all the interactive element. So like for example, I use mouse and you can see I can hover over this export plus. So it's a link and then I can come here, click and search for something. I can click or go through all these things or hover and go through these things. So let's see how a keyboard user can access this. So I'm trying to press tab. So I press tab once, nothing happened. Actually, the focus is now on here. So I mean, the control is there, but you cannot see any outline on it. So we don't know where I am currently. So I press tab again. So it's on explore plus link now, but you still can't see anything. There is no visual feedback and hence the user who is just using a keyboard, they could be confused because they really don't know what's happening. I mean, I'm pressing tab, but I'm not going anywhere. So what's happening? I press tab again. I come to the search box. Now here it's visible because this is an input and I can come here, you can see some dropdowns. I press tab again. There is this outline on this search icon. This is how there should be some indication. So this is the indication which should be there on all the interactive elements so that the user are able to understand where they are currently because now I know exactly by seeing this black focus outline that hey, I am on this search icon. I press tab again. So but still nothing is happening. So I'm pressing tab multiple times. So at a point I am lost because I don't know where I am currently. So how do I proceed to buy anything from this website? So this is what whenever we are testing with a keyboard, we should see that are things like people can understand where they are in the flow when they are on a website or can they use the keyboard to trigger the action? So if there is a button, can they press enter and that button action starts happening and so on. So these are some of the things which we must test when we are using the keyboard. So yeah, this is what we can test with the keyboard. Then there are multiple automated tools which we can use to test the accessibility of our websites. So for example, there are things in DevTools, there are extensions which we can use. Lighthouse is there by default in our DevTools. So let's see. So for this one, what I have done is I have already ran the Lighthouse report, but let me show you how we can do that. So let's say if I open any website. So this is like one of the websites which I have created to share information on accessibility. So if you inspect any website, go to the Lighthouse. There in the DevTools, you can find a tab called Lighthouse. Here, there are multiple options in categories. We can select accessibility and the device as desktop and then click on generate report. When we do that, it reloads the page and gives a very nice overview of whether things are accessible or not. It also gives a score. Now here, I would like to say a very important thing, never get happy, even if it shows 100 because it itself says that this is not take care of 100% of accessibility issues. All the automated tools which we use, they will only take care of like 10 to 20, sorry, 30 to 40% of accessibility issues. So this 100 only means that I do not have those 30 to 40% of accessibility issues in my website. They also give you a list of what we can check additionally manually so that we take care that it is accessible or not. So this is a very nice tool. So let's go thus for Flipkart. So this is the result for Flipkart. If you can see, so it has scored of 63 and then it shows errors below like buttons don't have an accessible name. So it's talking about this search icon. So because it's just a button, there is no label to it. So when the screen reader will go, they will just pronounce button for it. So if the user who is only relying on screen reader to understand what is happening on the screen, they will only hear buttons. So they won't be able to understand what that button does. Then images don't have alt. So there are multiple images on this website, which do not have an alt tag. So when they don't have alt tag, the person who is not able to see again, who is totally reliant on screen readers, they won't be able to understand that what that represents or if that information is useful to me or not. So and there are other things like contrast. So this gives a very nice information. And also you can click on the elements to go to that here in your elements pane and see what exactly is the issue and you can fix this. So there is one more which is called X. So Lighthouse comes by default. For X, you have to install it. But a point to note here is Lighthouse also under the hood works on apps principles. So you can use either of these tools. Then there is also extension, which I really like using, which is Wave browser extension. So for this, what you can do, you can install it in your browser and it gets installed as an extension. So for that, you right click anywhere on the website and save Wave this page. And it will give you error and all the overview of the things. I like this a lot because it also gives you a very nice structure of your website, like how your website is structured and for the errors, it also gives you error information. So if you like, click on any error, I think it gives information, maybe it's in summary somewhere. Yeah, so it gives you information of the error. So like what is the information about that error and it also links it to the specific workout guidelines so that you can go and read it. So it's also a very nice tool. The third one is screen readers. So screen readers are like really sometimes hard to understand when we are starting off. There are screen readers for all different operating systems and mobile. So we will always get a screen reader coming with our operating system. Like for Windows, also there is a screen reader, which is already there. And also there is NVDA, which is free, which we can install and check for accessibility. So this is also very nice. But for screen readers, sometimes it takes time to understand what are the different flow and how user might be using. There are also certain shortcuts which the user use. So they don't always rely on the tap, tap, tap and arrow. They also use certain shortcuts. Like if they want to just see the links or just the headings, they have different shortcuts for those. So whatever screen reader you are trying to learn or use, you can go ahead and check for their shortcuts and try to understand how the users use it. So DQ University is a very nice website in this case also, it provides a very nice information on these things. And if we test with screen readers too, it really gives a nice insight of what exactly our end user might be having the experience with our website and application. So now that we have spent some time in understanding that how we can test for accessibility of our websites, let's see how we can fix some of the common ones. So I picked some of the common accessibility errors which always are there. And let's see how we can fix that. So the first thing which is like really important and I believe that many developers get it wrong, but it's really, really important is using the semantic HTML tags. So often what we end up doing developers that creating everything with diffs and spans, just everything. Because with JavaScript, you can attach any event to like any tag. So buttons, anchor tags, everything we have, maybe we have to create a styled beautiful kind of button or something. And we end up using diffs for it and attach the on click. So don't do that. That is my advice. Use the semantic HTML tags, which were meant for that purpose, like button, button have a specific purpose, buttons mean that some action will happen if the user clicks on it or triggers the action on it. And then there are anchor tags. Anchor tags means whenever you have to go for navigation, like you need to navigate the user to some other place, whether within your website or outside your website. So for that, there is a specific tag which is anchor tag. Then there are form elements. So there are lots of semantic HTML tags which we should be using so that it creates a good markup which is understandable. And if we are creating a valid markup, like valid HTML structure, then it will be automatically be accessible and understood by the assistive technology. So let's see an example of it. So I have just created some basic examples of how we can check for accessibility. So let me open it up. Yeah, this one. I think, yeah. So what I like, I can show you that you can use any kind of tag to create buttons and it will just look like button, right? So I've created two buttons here. One is using normal button tag and one is using div. Now, someone who just uses mouse can click on these and the both will work the same way. So for now, I've just put console lock on these two. But let's say a user is using a keyboard and like keyboard and screen reader combination to go through all the buttons. So they will use tab. So I press tab here. So there is this black outline on it too, which says that, okay, this button is in focus and screen reader will pronounce the name that this is the button and then they can use enter or to trigger the action. So I pressed enter and the action was triggered. Now, if that person wants to go to maybe some other button too, so if they press tab again, you see this button totally got skipped. So if I cannot see, I will never even know that there was another button there because that's not in the flow and that's not interactive to definitely not meant to be acted upon. So now, if I'm using any non semantic HTML tag, then I have just made it inaccessible to the user. So how to make it accessible is first thing, definitely, which is most important is using HTML tags or use button. Whenever you have to create a button, use button. But then I also saw another way of making it because there are many places in which we have already like in existing applications that we have like created complex markup and we have created different all. So how can you still make it accessible? So if you want to make the existing things accessible, first of all, you go ahead and change it to button if you can, but if you can't. So first, there are multiple things which you need to do in order to make things accessible. The first thing is that it should be in the flow, like the user should first be able to reach to that button in order to act on it, right? So for that, you have tab index. So tab index is in HTML also, but in HTML, you will find it with small I in a react. The I is capital in tab index, and then you can set it to zero. So when I set it to zero, I want to say that, hey, I want to make this tab available and in the flow of the element. So now if I press tab, still I came to this div, okay? So this div is accessible now, but still can I really act on it? So I'm trying to press enter, but nothing is happening here. Why? Because I have written on click on it. So on click, when you are creating again, the semantic HTML tags there, the keyboard accessibility comes out of the box because they know that, okay, it's a button. So on click means the user should be able to use keyboard as well and able to trigger the action. But when you are using a non semantic HTML, then on click specifically means on click. So it can be triggered only using mouse. So what do we do when I want to make it keyboard accessible? So for that, I will have to use a key down event maybe, okay? So in key down event, let me copy paste otherwise. So yeah, what we can do in the key down event is whatever event is there. Now key down event will fire on every click, every key press, but I don't want to have that. I just want to trigger action when either enter keys pressed or either space bar is pressed. Now space is also for buttons. If you read the accessibility guidelines, buttons can be triggered via either space bar press or enter press. So I will check for keys that which keys getting pressed. So if space or enter is pressed, I will go ahead and do the same action which I am doing on the on click. And also one more thing to remember here, because this is if the space bar is pressed, the by default action of a space is to scroll the page. So it is also one of the accessibility features that whenever you press the space bar, the page scrolls. But in this case, whenever the user uses space press on any button, I don't want to have paste to scroll. So I will have to prevent default event. So now if I save this and go here. So I am using enter or space bar both. So you see that event is triggered. So this is one of the ways in which if you are facing some issues, so you can make how you can make things keyboard accessible. And this is just about button, but normally there are multiple more things when we end up creating complex elements and we want them to be accessible. So we can use these tricks to make those accessible. So yeah, using buttons and anchor text. Now I want to talk about anchor text again, because this is very important. I have seen it at multiple places. So in multiple markup, I've seen that what people do that they use buttons and they style it like a link. So let's say I want to have multiple links. I use button and I styled it as a link. For example, this one is a button which is getting displayed as a link while the second one is a real anchor tag. So the main issue with this is now they both are clickable. They both will take you to their destination. So you might say that what could be the issue? The main issue which I find here is that remember I told you that when users use screen readers, they don't just tab on it and go to all the links and button. They have these shortcuts. So let me once trigger NVDA and I will show you. So I'm using NVDA screen reader to show things. Okay, so I'm on my website and what I will do that I'm trying to extract all the links. So I just want to go through all the links maybe. So for that there is a shortcut for NVDA on Windows which is insert plus F7. So I have not figured out how to zoom it in this popup. So somehow I can't zoom here. But if you can still see there are different types of options, links, headings, form fields, buttons and landmarks. So if I'm trying to let's say I have a website and all the links I have created may be using button tag. So they look like a link but internally they are not a link. So if someone comes to my website and they want to see what are the different links on the website and they want to quickly go through all the links. So they won't find that link in this tab. So yeah, so if you can see here I have this go to stack overflow. This is using anchor tag but I don't have the first anchor here. So that is listed as part of buttons group. Yeah. So that's why whenever we always use the right CMRT HTML tags when we have to use it so that we don't end up confusing our users. Okay. So next is forms. So forms are everywhere like almost everywhere whenever we have to log in sign up we have to get the users to fill some details for payments everywhere like we want users to fill some forms. So they should be accessible because then only users will be able to fill it properly or specifically if it's a payment form because if users won't be able to pay then it will be really bad for your business. So let's see some of the examples of form accessibility. So this is one of the basic things like we should be labeling our form inputs but still you will see this error on like a lots of pages. On lots of pages you will find that the forms are not labeled correctly. The inputs are not labeled correctly. So for example here I have a form where let's say on my website somewhere I have a sign into Twitter thing. So email and password but there is no label because the design they are like okay we don't need labels we will just have some inputs and a button. Now if I am a cited user I can see this and maybe understand okay but for screen reader users they are totally reliant on the labels to understand what they have to fill into these inputs. So let me start the nvd again. So here it's reading the placeholder but most of the times they don't read even placeholder and the second issue is when you start editing it. So and let's say it's a big form okay so if it would be a big form and let's say I filled something right. So after you fill things and it's a big form let's say 10 you might be confused as well if even if you are a cited user that okay what was there to fill in it one and if I filled it right or not. So labels should always be there but when the users use labels and I recently saw a very bad marker about that so I'm going to talk about that too. So I want to label it so how do I label I write label and email. So I have seen this at multiple places we just go ahead and write labels in our password in top of the inputs. So if you see this again you can see these labels here but they are not always connected. So if you go ahead and check the accessibility tree so you can check the accessibility tree of everything that you are creating just inspect your website and in elements pane of elements tab here you can see different types of options right styles computed in the if you have to click on this and go to accessibility and here I can find this accessibility accessibility pane and this tree is called accessibility tree and you get to know from this accessibility tree that what information is it passing on to assistive technology. So for this this is really smart because it is taking up the placeholder but if there were no placeholder then there would be no information on how the labels are coming in. So let's say in placeholder instead of this I might have something else or if I don't have anything because sometimes we fill it with example of what it is so now there is nothing there so there is no label here because that information I haven't provided I have provided label but I haven't said that this label is for which element so for that we can assign it add okay I already have an id so what we can do is again in html we use for for equal to and then we say the id of the element so I want to say that hey I want to have this label for this element so this is what is meant by for but in react you can have it with html for because in react j6 is written in javascript so for is a reserved keyword so we use html for here so if I do this and come here now you can see that it is labeled by the label and you get the label here properly email so always use the label and I'm use label only mostly because I have seen someone using paragraph recently and it was like we really are using anything to just so text so using always use labels and label them properly now this again there is one more thing here what if the design is adamant that oh no I don't want to have any labels like from UI perspective I just want to have these or two input boxes only in that case also I always say that as a developer it's our response ready to make things accessible so what we can do is have this label and go ahead and hide this using the any class so there is this reusable class which is which you can use so there is this styling what it does that it hides that text or anything where you put this class on from UI so this won't be seen this won't be visible but still this is in the DOM so it will be pronounced by the assistive technology or it will be like exposed to the assistive technology you can give this any name so lot of convention they use SR only means screen reader only so you can use this and then if I put a class of this here so let's say in any case I have to like maybe not show it on the UI still I still want to make it accessible and want to show it to the assistive technologies so this happened so now if I inspect it you can see that it still is taking this label but that is not visible on UI so we still made it accessible the second thing here is again for icon only button so let's say if there is a button which just has an icon so if we check the accessibility of this button now this is just a generic there is no label nothing no title on it so when the screen readers will pronounce they will just say button so I don't know what that does right so for that we must always provide a label to it even if we have to hide it from the UI so how you can do that so this is the button so if you see the markup I have a button with which has a icon inside it and a class name which shows the Twitter icon on that but if I want to label it I can say aria okay aria label and you can say to Twitter like give it a label give it a nice label so that this is what is pronounced to the disk and now this icon I don't need to expose this so if there is something which I don't want exposed you can add a aria hidden tag to it aria hidden property okay so if you say that it's aria hidden it won't be exposed and because we already have a button which says that hey sign into the Twitter now yeah if we come here you can see now this button has a label and it's reading it from here so if I start again nvda so if you can see it just read out sign into twitter button what if I so now let's it's just told button if there was no aria label and when I added aria label it read that so yeah so this is a nice way but again aria label is one thing but if you are using localization on your website so I read recently that aria label they don't get internationalized so they don't get converted into a different language so in that case we can use aria labeled by so why aria label doesn't get because we are passing the text here so what we can do is there are two different ways in which we can do and it will still respect the localization settings so let's say we can create a span and give it a id maybe something called button label and then I use the text here okay and what I can say instead of saying aria label when we say aria label we give the label there as a value but there is something called aria labeled by okay so what it does aria labeled by it takes the id of the element so by doing so I am telling that hey this button is going to be labeled by this element okay so when we do this again and we write this a span here this is going to show so I can use the previous class sr only so that it's not visible on ui so if you can see this here and I inspect and show you it again says sign into twitter but now it's taking it from that span because I have attached the aria labeled by now these are these can be localized so there is no issue with their localization so that issue is also solved then now that I see this there is also a third way I don't want to use any aria maybe because I am already using a span and I can hide it from the UI why not use this span inside the button because any text content which you have inside the button that will get read out right so this is a span I want it inside the button maybe so let me remove aria labeled by and what I have here I have a button and in button inside with an icon I have one extra span and I say that hey this span should not be visible on ui but still it has this text so now if I save this again you can see that inspect this button so now this button still has it by default it's content so because there is a text content inside it that will be read out so it's still accessible so there are different ways in which you can do it so depending upon your requirement so because this is the one which I prefer now that I have read it because yeah this does not require any aria and aria should be like really used when like a desperate measures like you are not able to make it accessible by any other measures then try to use aria but otherwise we can use the markups to make things accessible so let's get back to the ppt so we saw how to label the form inputs and also yeah don't hide outline so if you see here whenever I'm tabbing there is no outline so you cannot see now I have tabbed and my focus is on this twitter icon but you cannot see that right because the culprit is which is again in like I don't know how what percent I could say but at least 90% of website what they do is they have this outline none like set on root they don't want to show anything like no outline so this is a really bad practice because unless you have a different outline styling so you can do this definitely but if you have some other styling on it so for example in this website itself I have I think I don't have an outline because I want to have a different kind of styling so if you see I have a different nice kind of styling on some of these so that's why on these I might have hidden outline but what I want to say that always have some sort of visible indication just not hide outline and don't do anything which I was doing here so I have hidden outline on all of these so the visual indication will not be here so this is the culprit just just don't do this this is very bad so let me remove this because let's remove it or add your own styling but don't leave it like that so now if you can see these are outlines which are coming this can again be styled to make it nice circle or anything which you want but it can definitely be styled so now it's giving very nice visual feedback and yeah using aria we saw how to use aria for label we saw aria label but it messes with the localization so we can use aria label by or we can use a span then one more thing which is a I want to talk about today is aria required what aria required does so for example for this website I have these two both as required so there are two ways in which we can mark things required so what we do we can say that here this is required field okay so my email and password they both are required so what it does that when I click on it it it gives up like it's a default of browser so it gives a default error but what happens that we might have some errors of our own to show so we want to show some errors and we don't want to maybe show this default error so what we do we don't use this and we we remove this and instead let's say I'm trying to show our error so I have written some simple logic that if there is no data just show error and I want to show error message to the user instead of that pop which was coming up so now if I'm trying to enter so it gives color and these errors right so this is there but how does the user know that this field was required so when we saw the screen reader pronouncing this they never told that it was a required field so how would user know in first place that it is required so if we had used that required field then it shows that it's required but now I have removed that because I want to have my own error messages so now there is no way that the screen reader or assistive technology they know it's required so if you can see here it says required false but I have required true so in that case what we can do that use the area required and set it to true so when we do this now you can see that it says that inaccessibility pain where we are seeing all this access between formation you can check here this is a very nice handy tool you can check that it says that it is required true right okay so so use this if you are not using the required so always use area required on your required elements then don't rely only on colors why I say this is because let's say here I am already many times we will see just a visual feedback of errors so for example here I click on this and we show this red color right red means okay there is some error in it now why this is we should not be relying only on color is because what if a user has some sort of color blindness so you can emulate the color blindness again in your depth tools by going to the rendering pane so if in in your depth tools in elements pane there is something called rendering and in the rendering if you scroll down you can emulate different type of vision deficiency now let's say a person who has acromatopsia they are visiting this website and they are trying to do something and I am relying only on color to show the error so this is how it looks to the person with acromatopsia so they can only see in the gray scale black white gray so they won't be able to understand what color it is and so all the information which we are displaying just in color form will like not be accessible to those so in that case if we have a very nice errors that is good because even if they can't figure it out by colors they can figure it out by the error below right so let me go ahead remove this this is one thing now the second thing is why we have the errors here we can see it right that there were some errors and we can go ahead and fix it but let's say again a user who is using screen readers for them they won't know about this information because we are not telling them that here there is some extra text below or there is some error right so for that we need to announce these error messages to our screen reader users so for example let me go ahead and tell here so we have these properties where we can say that uh I will say that hey you need to show this so there is uh aria live polite which means that whenever a new message comes in or some text gets appended to that that div or something you need to announce that to the user and the role of status again it's the html attribute only uh normally only one of those would work but I have read that sometimes one or the other doesn't work so we can use the combination of these so they do nothing from a ui perspective so you won't see any change on the ui but it does a lot for the screen reader users so for example okay I think I will just demo it once uh so so I will try to press this and we will see okay I did something wrong this should not be an issue the role aria live equal to polite I think I messed up with something this should have worked or I'm doing something wrong so never mind I this example definitely went astray but still this is the way to do it I will figure it out what went wrong maybe I'm doing something wrong here and I will tweet it out if I get what was the issue but still whenever we have something dynamic happening and we want to show that important information to the user we should be using these roles and aria live so that they get announced to the user okay so let's see so we saw how to we should not rely only on colors and we should show the messages as well and also how to announce important details then uh these are things which I want to highlight because whenever we are writing j6 there are subtle differences uh with html uh some of the most important ones are tab index like it's all small in html but we have i capital in j6 syntax then on click whenever we are adding on click handler again it's in all small when we are using html but when we are using j6 uh that c is again a capital then for uh for becomes html for when we are using the react code okay so and then uh the last thing which I want to discuss are useful tools and extensions so we have this plugin eslin plugin for j6 ali uh you install it and it will give very uh nice information about uh linting information if you have accessibility issues like let's say you have an image and you have not provided an alt then it will give you a warning that you don't have alt or if you try to use div and on click so it gives a nice one you can use it with your linting uh then we have react acts wave we already saw then there is chrome walks this is kind of a screen reader but for chrome browser uh so you can also install the chrome walks and use it as a screen reader for your browser these are some of the resources which have nice information about accessibility so this is an official react documentation they have very nice documentation about accessibility then uh we have authoring practices by arya they are really nice dq has very nice resources on accessibility and then uh this is the website which i created explore accessibility uh i try to curate the links and some of the examples which will be helpful when understanding accessibility so take a look at these whenever you have time i will be sharing this of pipity so that you can get access to all the links to summarize the access to information is the right of every person so whenever we are creating something whenever we are building anything we must always think from accessibility perspective we must think from like how users will they be able to use it properly or not so you can use aria to enhance accessibility but aria should always be handled with care because if we write wrong aria then it it might make things inaccessible as well so as i told earlier also like aria should always be the last resort in most of the cases we would be able to make things accessible without using any aria but if we need to use it like read it and don't use like try to use proper aria and whatever we are creating always tested so not only test with mouse test with all different things also test with your keyboard and test with different tools and extensions to understand what is the accessibility state of your website so because when we think about accessibility from the very start it's very easy to make things accessible uh but if we make the whole product and then try to make things accessible then it takes a lot of work so always start from accessibility perspective from the very beginning i also have action items for you today so if you learn something so pass on the learning and let's spread the awareness around accessibility let other people also know talk to it talk about it to your teammates your friends and let's all work together to create an inclusive web so you can also find the resources if you scan this QR code here or you visit the website the link at t.ly forward slash in capital if s o okay it also has a feedback link so do provide feedback for this talk so that if you have any points for me i will try to take it up thanks a lot it was very nice presenting and i can take the questions thank you another there was such a great talk if you have any questions you can drop in the chat meanwhile there are a few questions so i'll go ahead and ask them so there's this question by such a group he says uh ui wise won't be outlined with the border or any box shadow look weird when you're trying to concentrate on focus i think it's a most asked question when we say we should not avoid the focus outline so yeah so for that like i told that you can definitely style it so for example for my this website what i have done is if you see i have styled it they are not using that black outline so it's upon you and if you go to different websites you will find that they have very different cool and very nice ways of you know uh showing these uh i think uh there is this website i forgot but uh the point i'm trying to say is if you think that that this black outline or blue outline whatever is depending upon a browser if it looks not so good to you so definitely you can go ahead and use a different styling but don't hide it because you know how it's like i try to always say that if you are using a mouse and someone takes away the cursor what if this cursor is invisible so how will you be able to navigate this website if you cannot see your cursor so this is the same uh outline works as the same thing for the keyboard users so if you take away the outline they won't be able to navigate and if they are not able to use your website then you are losing on customers and also there are legal legal problems if the website is inaccessible so uh i think uh it's best to always keep these things in mind and make it accessible and yeah make go ahead and be creative and try to make different kinds of outlines there are also dashed outlines and so on so yeah take your pick but just don't hide it yeah there's one more question uh from this person i think he asked in context with uh when you were explaining uh uh button uh as a div so he's asking if there are any uh trial and error kind of check for these elements when you're not using semantic html elements so how can we test that uh can you just repeat because i lost you for a moment okay uh so sachin is asking another question this was in context when you were explaining that you're using a div as a button so he's asking is there any trial and error kind of check for such elements when in the case when you're not using semantic html uh so that again the check would be uh using keyboards mainly so for example uh how i found out that this is not accessible i use the keyboard and i was not able to access it so uh any element uh which is supposed to be uh you know uh supposed to be interactive and if you are trying to test it with different assistive technology like uh keyboard or screen readers and you see that uh hey this doesn't seem accessible or hey i cannot operate on it or i cannot go through it go not reach to it so that should be your cue that i'm doing something wrong there and i need to fix this and also i would like to tell you a very nice resource where is uh just give me uh yeah this one i always say people to visit this one whenever you are creating anything and you feel that i need to test that whatever i'm creating is it accessible or not come to these why aria authoring practices this is the official one and i agree this is somewhat overwhelming because there is lots of information and sometimes you might feel lost but still for example uh let's go to maybe model so i'm trying to create a model so when you have created it come here go to that and read it that what are those interactions like read this so this says that when model opens the focus moves to an element inside the dialogue so you try to open your model via keyboard and see that if the focus moves inside your uh you know dialogue so read all these and check so use these as your checklist and then you will get to know that if you are creating it in a right way or not so this is the best website to like you know check for every element so it it can consist of uh all the nice uh controls which we can have and either these or you will have a combination of these so this almost covers for most i think almost all of those yeah uh moving on uh saga asks what does role equal to button on a div team and in continuation even harsh is asking how important are these role and title attributes yes so uh yeah so uh when you are using a button then you don't need to use a role on the button but if you are using a div tag uh so if you say role equal to button what it does that the role is actually uh that is an information which you are passing on to the assistive technology again like a screen reader in this case so uh for example in here where we had this div now if you see i don't have a role on it so let's go ahead and see what is being shown on this uh accessibility tree okay it's a generic right so uh when the screen readers announce it they won't say that it is a button they will just say using div but if i use a role here now which i should have i think i missed it so it's a nice question thank you for asking uh so we must always attach the role so that this gets exposed so now if you see it was a generic before now it says that it's a button so in accessibility tree you can see that okay the role is button so this is a button so when the screen reader will come to it they will announce using div button so i mean they will announce the user that hey the element which you have come across is button so that is the importance of role they will let the users know that what exactly that thing do now if you're using semantic HTML you i think uh roles are not much relevant unless we are using one thing for the other like we might be using let's say checkbox we might be using the checkbox for some we create switches using checkbox right so we can create switches using checkbox so in that case we can set maybe role to switch or something so that it says that okay what you have encountered but the main purpose of role is to expose what is the that element and that to the user and how important are the role and title attributes so yeah role is really important because it it lets the user know that what exactly is that element so because in the user's head let's say i cannot see so for me if someone says that it's a button that's my queue that i can click on it like i can trigger any action on it but if there is no role announced to me i might think that okay this is just a text or something right so that is a queue like i know certain things i know certain element they perform different role and title is again a title is important the sense what whenever you attach a title you hover over it and you can see it so it is important again because sometimes when things are not you know that evident so like for example here so we all know that it's a twitter icon but let's say someone who doesn't know about twitter for this visually this is not giving any information but if i attach a title to it then if i hover over it like and i will see that title name on it so i will say it will be say let's say login to twitter or something so i can hover and understand what this will do so that's why title is again important uh i see one more question i hope this answers the question right uh so let me know if someone asks again on any answer uh it was quite clear okay and there is this question what is your opinion on when to use a button versus an anchor tag so uh how i uh draw the line is button should do any action anchor should take me somewhere so like uh if like the navigation or anything which takes me somewhere even if inside the website or maybe some new tab or something so but anchor should be used only when it's taking you somewhere it's not performing something but button like what button can do they can submit some data for you they can show some more information to you so they can do some action for you and so that is the distinction which i take between button and an anchor tag yeah i think we are about time but if it's okay by you can we take a field yeah yeah yeah please yeah so uh i think on the youtube there's this question coming that is there any way to test mobile site without having a physical device or any tools which can help with the accessibility testing of my application uh for mobile because i have never worked on mobile much uh so uh but i do know that like screen readers there are uh voice overs for mobile so in your android or iphone also you will find uh voice overs uh and they can be used to understand how you just go through it but then again uh how to test it using browser like not using a physical mobile that is something i will maybe search and let you know but at this point i don't have any answer top of the head for that there was this one last question by satish and i would also like to know the answer there's a react developer what unique hurdle a developer faces when making the accessible site and since react is a lot about making reusable components so is there something that we should keep in mind in the initial stages when we're trying to build our code so that it the components are as accessible as it can be yes so yeah so in react that definitely is a hurdle because there is a mind even a mindset shift you know when you are writing html you go on writing things like button drop down everything but when you are using a react what we do we create a reusable component called button and so now you have already created a reusable component called button or header then what we often do is we use that element and in my mind it's like okay i'm already using a button so it feels semantic but it's not it's just a react component so you need to write button inside that button component in order to make it accessible right so yeah and reusability is again a very important i think it's a strong point of react because then you can create an accessible element and then you can component and you can use it across your website so the main hurdle i would say that don't think about the component name and think that it is accessible or so always check the markup whatever you are writing in j6 so that is going to translate to this html so that is going to translate to these DOM elements right so always come and check what it led to like how it was you know shown or how it converted into a DOM so always check this resultant markup and then you should be fine and yeah it's it's really important to take it from the very start like for example if you're trying to create a button why not create it button from the very start and like why to make it as a div and then when someone raises accessibility bug in your QA environment or production and then you go ahead and fix it so that is a lot of effort duplication and cost right so why not make it accessible from the very start so our effort is also reduced we make things right from the very start yeah i mean that's such a good advice i think that's about it that's all the question that we address and anyways i think you can let us know where people can contact you just in case if they have more doubts after they get access to the resources and everything so yeah i will ping you yeah and in that i think someone yeah hush mentioned in this chat right so the link which i told in which it was smaller l and not i so sorry for that but yeah that link definitely you can ping tanisha in the youtube so they will they will get all the you know slide link as well and there is a feedback form link as well as linkedin and twitter link also inside it so feel free to reach out to me and yeah i would love to discuss more about accessibility thank you so much i think we have Anuradha's twitter handle attached in our posts so you can definitely contact her if you have any other doubts and thank you so much for such a wonderful session it was really a pleasure to host you thank you thank you it was oh yeah very nice presenting here and i hope people found it helpful and thank you for everybody joining in from the live stream and the zoom for having here hopefully you had a great time thank you thank you bye everyone thank you