 So, you can see a QR code on the screen right now and that's the beauty of this presentation because it is accessibility compliant, that means whenever we are presenting it should be accessible as well to all others. So, here's the QR code if you want to scan or you can go to the link to get all the slides, I'll wait for a minute for those who are scanning it. So, till here I want to explain you about what I am going to cover in this presentation. So, you might have seen accessibility as a huge concern after or you can say a kind of concern for everyone in Eastern Europe or America where they have such acts like American Disability Act. It is coming on a global level right now and if we are developers and we are just coding rather than thinking like why and how these accessibility features are important to us, we may get into trouble in future. So, this talk is going to focus on writing code but keeping accessibility in mind. So, I am a Google Developer Expert and an open source enthusiast working towards web accessibility and usability. Web accessibility, let me define it again. Web accessibility means that people with disabilities can use the web right. So, it seems a very simple definition but when we actually apply it, there is huge cycle of learning involved. Now, for web accessibility, W3C which is the parent organization of internet has written some rules and we call these rules WCAG which means web content accessibility guidelines. These are the guidelines, these are the standards that we should keep in mind while designing a web application. In your industries, whenever you are going and writing code, you need to keep these guidelines into your mind while writing code. We will walk through each and every guideline and the things we are often do that we should not do and we should learn today so that we can avoid those mistakes. But why? Why should we learn about accessibility or why should we consider the WCAG guidelines? Before you understand the why, let's go through some user stories. A person, Kyle, is having vision disability. Now, Kyle always wants to stay away from online classes. Whenever Kyle go for any online class, he feels it very difficult to understand because he cannot walk through the course as the website is not accessible. Kyle got frustrated and people like Kyle just assume that 90% of websites with online courses are not accessible. So they don't go to the websites. Gordon is another example. Gordon is having a motor disability. So Gordon uses mouth stick to type. Now, Gordon cannot use mouse because he feels frustrated with mouse. He uses mouse stick. Gordon can access the computer but not the web because the web is not accessible with the mouse stick. It is accessible a bit with mouse. Curtis is another example. Curtis is having hearing disability, which means Curtis cannot listen. Curtis can only see. So whenever there is a video without any subtitles, it does not make sense to Curtis. So what Curtis do is it follows the video with its intuition. So whatever comes like intuition, Curtis thinks like whatever is going through the video, it is telling him a story. Now it's not about Curtis, Gordon, Kyle. It is about 217 million people on this planet who are dealing with the same kind of problem and 37 million people of them are blind. So you can see such a huge number. So you are not talking about three to four people sitting in a row. You are talking about 217 million people for which you can make a website, right? Now it's not only about empathy. It's also about business. It's also about legalities. Now when I talk about this topic to many developers, they always think it unrelated kind with an empathy angle. They say, okay, we'll care about those people, we should come forward and we should make website. Now there is another angle of this whole cycle and that angle is business. If people like Kyle are not going to such as Coursera type of websites, if they are not accessible, they will choose to go or they will force to go to their competitors like EDX. Now two competitors fighting for a market share will lose 217 million people on this earth if their websites are not WCAG compliant. It's a total business loss. It's not only about empathy and business. It's also about legalities. There are different acts that are coming into the scene today. One of the act which I have studied was American Disability Act that is only applicable to a company who is registered in America. But then there is European Disability Act for the companies who are in Europe and then there is Australian Disability Act for the companies who are in Australia. People are getting aware and it's the time to make ourselves aware. So I'm going through the rules now which will help you to think in this direction. Now we need to change the thinking as well. How we think we browse web. Do you know any other way of browsing web? Anyone? Okay. I can see mouse and a keyboard on the screen. What is another way of browsing the internet, mobile? Any device, any hardware apart from mouse and keyboard, touch screen you are talking about maybe, yes. But how people browse the web, I'll let you know today. There are blind people who use screen reader. There are people who feels frustrated using a mouse. So they use mouse stick. There are people with headbands and the list is going and going and going, right? We need to change the perception and these are the specific type of disabilities that most of the people are facing. Hyperactivity disorders, blindness, low vision, hard of hearing, speech and language disabilities, brain injuries, physical disabilities. We see the user agent, the browsers and every time we are stuck into very, very little problems such as making a website responsive. So we start working with Chrome. We make the website responsive for Chrome. We take that website to Mozilla. We try the same things and check if Mozilla has a breaking feature. We take it to Safari. We just care till our browser list ends and that's all, right? But these are not the only user agents. These user agents are screen readers. Screen readers are used by disabled people. disabled people are not aware of which browser it is. They're more aware of how that website reacts to their screen readers. If your website is having very good user experience but at the end it is not accessible to a screen reader, it is of no use for a low vision or a blind person. It is not only about screen readers as well. There are magnifiers which are the user agents. People with low vision also uses magnifiers. So whenever we design, we need to think about the browsers, obviously. We need to think about the screen readers. We need to think about the magnifiers. We need to think about the other devices such as mouse sticks and headbands. Now obviously we cannot make a website and can check all of these platforms but there are certain standards that we can follow. If you are aware of those standards, these standards make sure that the website you are making with those standards will be compliant to all these platforms. So the standard are WCAG and WCAG has four specific principles, Perceivable, Operable, Understandable and Robust. Now we will go through each of them with examples and we will see how these features can be applied to your websites. Every feature out of them have their own success criteria. These success criteria make sure that you have applied the feature correctly to your website. Each and every feature have their compliance levels, which means you either need to achieve one of the compliance levels. You may achieve A, you may achieve AA, you may achieve AAA. AAA is the toughest one to achieve for a website. So generally we prefer all the features till the AA compliance. If you have achieved AA compliance, that means a lot. So let's go with Perceivable. Perceivable stands for this piece of information. You have the UI components, but you have to represent them so that your users can perceive the information. Let's take an example of an alt text, which you use or may skip whenever you have an image. Whenever you have an image, there is a choice of having an alt attribute. Some people write it, some people miss it, but the alt attribute is a specific information for a screen reader. For a blind person, image does not make sense. So the screen reader starts finding the alt tag and when it gets the alt tag, it starts reading that this image means this. Now sometimes we don't know the alt tag for a particular image. So we skip writing it. Instead of the W3C guidelines suggest that if you don't have an alt tag, write alt and make it blank so that the screen reader skip the image rather than reading the HTTP URL of the image. Just assume how it will sound if your screen reader is going through a page, it comes towards an image, and it starts reading, I got HTTPS, Amazon.in, forward slash, this, this, forward slash, this, and the person for which you have made the website is actually listening to this particular thing. It's vague. So if you make the alt tag blank, if you don't have any information about this image, it's far better than not writing the alt tag, right? Pre-recorded audio is the second guideline provided by a perceivable principle. There are various options available which are open source, and you can see the links which I have added here as well. There are free softwares, and then there is YouTube. Whenever you upload a video, you can get a transcript out of that video, and every time you write, you provide an audio to someone, always try to provide a transcript with the audio, right? Because people who can't see or people who can't listen can simplify their situation if you provide pre-recorded audio. Now there is a concept of pre-recorded video as well. If you see this piece of code written with video controls, there is a simple video, and then there are source, example.mp4, and two basically web formats, and track. So the track is the HTML tag where you can provide a VTT file, and that VTT file is basically the subtitles associated with that particular video. So you can make your own web VTT file, and what you need to just do is whenever you are using the video tag, you just need to use the track HTML element, and then have to provide that VTT file as the source of that track, color contrast. When I was giving these kind of talks everywhere, I asked people what is your fundamental problem? And most of the people came out with color contrast. We can't decide colors, so we decided randomly. I also surveyed and find out most of the designers don't even understand accessibility. There's a huge gap between seeing something very beautiful, making the user experience perfect, and making it accessible, and that balance is very important. Color contrast can be achieved with the simplest double A compliance using some tools. Maintaining color contrast is a challenge, because you need to maintain the contrast between the background and the foreground color. Black on white always looks good in terms of accessibility, but when you take a shade of black over white, then you start decreasing the compliance levels, because that is visible to you, does not mean that will be visible to everyone, because you and the other person have different kind of vision problems. Orientation, restricting the orientation is also one of the issues that comes under a perceivable. If you restrict the orientation of your website into landscape or portrait, there are people with motor disabilities, there are people who cannot move much with their neck having some neck issues, so they prefer the different kind of orientation in a single device. Face text, say no to pixels. Every time I see a website, the first thing I check is the font size. Are you still using pixels to give a font size? Very basics, right? But that basic becomes a problem when you start asking a person with low vision what he's seeing on your page on mobile. So there are specific units for font sizes apart from pixels such as EM, REM, which you should use, which are relative, relative to their parent, relative to the whole HTML page. You should use these units instead of hard coding pixels. The second principle after perceivable is operable. The interface elements which you are designing must be operable. Now this definition will make sense when we go through certain examples. For example, if you talk about screen readers into the operable category, you will come across a common mistake. Can anybody figure out what is the mistake in these two lines? I have used a label with a for of username. I have input type text with name username. I have used a label because I want to make the screen reader capable of understanding my input box. The mistake here is when you run this piece of code with a screen reader, the screen reader read it as edit text blank. It does not know what this input box is meant for. I have corrected it with writing the ID into the input name. If you use the same ID with the full label mapping, for is username, ID is username, everything is fine. Now, when you run this piece of code, it will show username, edit text. So a person who can't see can actually listen to the screen reader saying username, edit text. There is a skip navigation functionality. If you go to internet and search what is a skip navigation, you might find there are persons who there are people who cannot go through the website with a screen reader all at once. Maybe your navigation bar is too big that a person wants to directly go to the content area, the main content area. So he has to skip the navigation bar. The skip navigation functionality is meant for the same. For the skip navigation functionality, you just write this piece of code where you hide the navigation bar from on focus, you just hide it and then you show it. So this piece of simple, this simple piece of code where you set top as minus 200 pixel for anchor tag, the skip to content anchor. You are seeing on the screen in the picture, the green skip to content. You just set the position fixed and you set the top as minus 200. So the skip to content is not visible on the screen. But whenever somebody focuses on the screen with a keyboard, you just write the skip to content in front of him. So he can tap and go directly to the main content area. This is the most funnest stuff I have learned in two years. The div is not equal to button. Generally, whenever I get a design from a designer, I start designing it. And if the button looks very fancy, I don't use the button tag. I remove the button tag completely, use the div, and start styling the division because it is quite easy, apart from messing up with the button styles provided by HTML. That looks super cool as a user experience, but in accessibility, you have lost a lot, right? So never replace the button tag with a simple div. Always use button because there are various features related to this button that are of use in terms of screen readers. Low vision impairment. So if this website is seen by disabled people with low vision, they may have seen this website with different angle apart from you. Now, the problem here is this website is blurred from the center. Generally, most of the low vision problems occurs at the ends. That's why it's super important to have different kind of margins and paddings on different sides of the page because there are people with low vision impairment who cannot see the end, generally. So you need to center align the content. Care about seizures. There was an incident happened in Japan, and most of the children were hospitalized on the same day due to a seizure, due to a Pokemon cartoon flash that happened. After that, people start taking seizures seriously. And here we are talking about seizures in web as well. So according to the guidelines, web pages should not contain anything that flashes more than three times in a single second. Whether you are animator or you are designing some beautiful animations, just try to take this into your consideration. Proper inputs. So we have label, we have span, you can see here. And then we have again span and then input. Now, I don't want to show this required star required to a screen reader because I don't want the screen reader to tell a person first name star. I just want to read first name, right? If you don't follow this technique, your screen reader should start reading this page as first name star. So you need to be smart here. You need to hide the star from a screen reader and you need to show the star to a person who is not disabled. You need to hide the required, which is written as a text, from a normal person and have to show required to a screen reader. So this piece of code where you have written visually hidden class and then aria hidden as true is doing the magic. The aria hidden true makes sure that a screen reader should not read this information. The visually hidden class in CSS makes sure that the required is not visible to a normal person. So you can keep this into your mind while writing any input box. Sometimes it's better to write repetitive code, right? So now we are going to a simple focus visible element. How many of you have written this line sometimes when while writing CSS? Sometimes, right? And then generally outline none is mostly common between front-end developers because they don't want that blue boxes of input which looks so weird for their user experience. But these boxes are super important for people who are using keyboard and navigating your page. When you type keyboard tab, these boxes appears one by one. So sometimes it's not a better idea to use outline none to remove the focus. Allow time independent interactions. The operable guidelines suggest to have turn off, adjust, and extend type of interactions. So just assume that you got a message. Congratulations, you have won the lottery of this much dollars. Click here for more information. And there is a timer that is going below it, 10, 9, 8, 7. You were not able to click, you lost all the dollars, right? Timing for you can be different from timing of other person. So if you take 10 seconds to click, maybe the other person takes 12 seconds to click. So you always need to make the page somehow, something like if the time is less, press the space bar to increase it. So that is called time independent interaction. So you don't need to force your users to complete a task within a time frame because there are people who are quite slow in doing that. And you don't want to show this message, session time out, right? Providing control to your users. Whenever you are using an animation, you are having a carousel on the page, you are having a beautiful animation running, always try to provide your users control. Always try to have these kind of buttons in your application where your user has the control of your website, where the user says, okay, I can stop it, I can replay it, I can pause it. Now this will help your users to avoid problems like seizures. If they have seizures with the flash running, they can stop it, right? So I'll go through understandable guideline now, and then the understandable guideline says to make your web pages readable. It looks like very basic here to write a language equal to en or a language equal to your language, but that's how all screen reader understand what is the language of the page, right? So if you are writing lang as en, actually it means a lot to a screen reader. If you skip this tag, this can be a problem. Input assistance. You always need to provide the actual message with the required, right? You need to write something like, if a user skips this entry, you need to provide a proper message, what it means for, so that the user understands what you are talking about. Make web pages predictable. Don't change the context just like on changing the focus. The last guideline is robust. Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies. Robust is a principle of future technologies. It says that whatever you are designing for today must be applicable to future as well. So you need to take care of valid HTML and IDs that should be unique on the page. Whenever I end my session, I always give more power to my developers. And this time, I'm introducing you to some tools which you can use in your day-to-day life to take all these principles into action. The first tool is accessibility Chrome extension, which you can download, and whenever you make a website, you can just play it so that it can make a DOM kind of tree, which we call it accessibility tree for you. It will tell you what is wrong and where, right? Here, your screen reader will not behave correctly, and here it will. So you can do some accessibility testing like that with this Chrome extension, where you can check the model just at the right, and you can check it is a button, and I should write it something like this. You can check that title is not specified in the image for that button, and you should specify the title of the button here. The next is the website, tenon.io. Though it is a paid website, but it has a free service as well. Tenon.io helps you to simplify the accessibility. You can provide a link of your website at tenon.io, and you can run the whole website test, and tenon.io gives you these kind of results, which says your page has this, this, this issues, and they will tell you to record it, download it as a CSV, or you can just check the errors right below it. The last, the next is color combination. The color combination feature helps you to have a correct ratio between the foreground and the background color, so that it can achieve a double A or a triple A compliance. You can set the compliance level as you can see here as triple A or double A, and that will check and set the foreground and background color palettes for you. It can give you the right color palette which you should use as a foreground and background colors. Total Y, I call it Total Y, but you can call it whatever you want, but this is from Khan Academy. This is a kind of bookmark which you can keep in your Chrome, and whenever you are working on a page or a website, or if you want to analyze any website, this bookmark gives you a lot of information like that and says your headings are not correct, your contrast ratios are not correct, you need to improve on text, your images are not having alt text, you are not designing your website, you know, keeping a screen reader in your mind. And a lot of issues are actually visible with a kind of format, just like try it, and you can try it and correct the mistakes. Chrome has already provided audit tab recently into the Chrome Developer Tools. You can run an audit of your website from Chrome Developer Tools itself and can check where your website, in terms of accessibility, where your website is not performing well. And you can see the whole report like that and the score that Chrome audit tools gives you, such as 74 or something, and you can improve the scores based on the report given to you below it. So just a quick wrap up, what we learned so far. WCAG 2.0 overview, how it is important, the four principles, Perceivable, Operable, Understandable, and Robbers, and finally the tools of accessibility testing. This is super important to learn and then apply using the tools because I believe human intervention is important, even if you have a lot of tools in your hand, right? It's human intervention and the tools which makes your websites accessible. So finally, you can follow this timeline of keeping every principle in your mind, starting from all types, captioning, contrast ratios, orientation, seizures, time independent interactions, give user control, resizing your text, skip navigation, keyboard navigation, making websites readable, making it predictable, unique IDs that comes under robust principles, validated HTML content, and finally error handling. So what are your next step? Whatever you are designing, whatever you have designed so far, just go through these three steps, run, fix, and then follow. So run a Chrome audit maybe today and fix issues, whatever comes in your mind in terms of Perceivable, Operable, Understandable, and Robbers, and finally follow some community like Accessible Community, Google Groups, or on GitHub and try to see what issues they're working on right now. If you want to collaborate or want to discuss, you can discuss as well. So finally, it is done from my side. If you have any questions, you can ask any questions. Here's my Medium, Twitter, and LinkedIn, which you can check. Do we have any questions? Yeah? Okay. So it's a good question. And yeah, I mean, whenever we have deadlines, it's very difficult to keep all these principles in mind because you need to somehow meet the deadlines. One of the things you can try is tenant.io-ci-cd integration. When you have tenant.io-ci-cd integrated in your project, whenever you push a comment on GitHub, it can give you a report if you are liking accessibility. It takes like two to three seconds to run the test. Any other questions? Okay. Thank you so much.