 Hey, everyone. Good afternoon. Welcome to Defconn's Tech 2023. Thank you for joining and we are really excited to have you all here today. I'm Aarti Kumar and I'm a software engineer at Red Hat. Before starting the presentation, let me ask you, are there any developers here? Great. Are there any front-end developers or UI UX designers as in? Also meant, are there any students or freshers? Okay. As developers, we have the power to create digital experiences that are inclusive to all users regardless of their ability or disability. In this presentation, we'll dive into the world of web accessibility and understand what it means to create and build application that are accessible to everyone. Trust me, the session is going to be really simple. I request you all to be mindful, sit back, relax, and let's learn together how to make the Internet a more inclusive place for all users. Before moving on to web accessibility, let's understand what is accessibility. Accessibility simply refers to creating products that are usable by everyone. This means any product from this water bottle to this laptop, everything should be accessible to all users. Now, web accessibility. Web accessibility is an inclusive practice of ensuring that there are no barriers that prevent interaction with or access to the websites on the world-wide web by people who are physically differently able. This means people who are having visual impairment or cognitive impairment or hearing impairment, etc. This is a permanent impairment, and the people who are temporarily differently able or situational differently able. This can be people who are unable to use the application because they have a broken arm or their eyes are covered due to an eye surgery. Or example, simply the mouse or touch pad doesn't work. So then we have to navigate through the application using keyboard. So this is also an example of situational accessibility. The third category is people who are socio-economically restricted on speed and bandwidth. These are users who live in a remote area or who are in a low bandwidth. Make sure our application is very light, that it will load even in remote and low bandwidth areas. Now, let's understand the why. Why should we create accessible application? We know that creating accessible application involves time, effort, and money. Then why should we create it? According to World Health Organization, around 1.3 billion users or people are differently able. That means one in six of us. These users are unable to use the application only because we created the applications in such a way that we haven't kept their requirements in our mind. So isn't that unfair that we ignore the requirement of these many users? Now, there is a business impact as well. For any product that is in the market or that is launching to the market, there is a set of potential users. For example, I have a product in the market and that is an online food delivery application. So let's take a sample of 100 potential users. In that 60% are my current active users and 40% are unable to use the application or they are not using the application. In that 40%, 30% people, just a second. In that 40%, 10% people chose not to use the application. And 30% people are unable to use the application only because my application is not accessible. So if we are making the application accessible, we can make at least 20% of this people to use our application. So when this 20% people can use our application, it'll benefit them as they can do or perform their task. As well as 20% people more using my application benefit the business or my business. So then the first 60% and the 20% make 80% of my potential users, which will positively impact my business. So creating accessible application is a win-win for both the business and the customers. So always keep in mind that when we create and or when we implement an accessibility feature, it not only support the people who are differently able, it benefit all the users. So that is why we should create accessible application. Now we'll understand how to create accessible application. In this module, we'll have a look into the different guidelines that we should follow to create accessible application. There are different methods that we use to enhance the accessibility of an application and an easy method to create accessible application, even if you are not a pro JavaScript or UI developer. Now, the first one, the guidelines. There are a set of guidelines or rules created by the accessibility expert of World Wide Web Consortium to create accessible applications in a methodical way. And these are called web content accessibility guidelines. And there are 13 guidelines under WCGA 2.1. And these 13 guidelines are organized under four principle. And these principles are organized by the, you know, called by the acronym PORE, where P is for Perceivable, O for Operable, U for Understandable, and R for Robust. And for all of these guidelines under this principle, they have success criteria. They have three levels of success criteria where level A is the minimum and the level triple A is the maximum. We'll have a look at the success criteria later. Now we'll have a look at the principles in detail. So the first principle, first principle P for Perceivable. Perceivable T principle state that the content should be presented in a way that it can be perceived by all users. This means that even if the user is visually impaired, he or she should be able to perceive the application using keyboard and a steep technology such as screen readers. This is the first principle, and now we'll go to a few guidelines under the first principle. Though the first one is text alternative. So when we add images, videos, or audios in the website, the people who can't see or hear won't be able to understand what is the content. Content, for these we need to add the text description of these non-text content. So these description are called the text alternative. So for example, if I need to add this image in the website, I should add the alternative text describing what this image is. So here in the example, you can see that the alternative text is a red apple sitting on a wooden table so the user can understand while screen reader reads the alternative text. So for any non-text content, we should add the text alternative. Now, the second guideline under perceivability is color contrast ratio. So there should be enough color contrast ratio between the text and the background color. And it should be at least 4.5 is to one. So take the first example. Here the text color is black and the background color is white, which is, we can see the text really clearly. And the contrast ratio is 21.0 is to one, which is really good. Now take another example where the text color is light blue and the background color is white. We cannot clearly see the text. In this case, the contrast ratio is 1.8 is to one, which is not good. So always make sure when you add any text, the contrast ratio should be sufficient. And the application should clearly work even in grayscale. I'll show a demo of grayscale at the end. Now the operability. Operable is the second principle of WCAG. Operable means that the user should be able to interact and navigate through the website using different input devices or their input devices of their choice. And the first principle guideline under operable is keyboard compatibility. The whole application should be navigable using keyboard and make sure there are no keyboard traps which prevent the user from navigating further from a specific point. The second principle, second guideline is input mechanism. For example, if the user is having some motor difficulty or a cognitive difficulty, they might use a mobile phone or a tab to navigate through the website. So make sure your website is navigable using touchscreen. So make sure your application is navigable using multiple input devices. So that's all about operability. Now we'll move to the third principle that is understandable. Understandable state that the content should be organized and presented in such a way that the user is able to understand the purpose and functionality of the page. Now we'll move on to the guidelines under understandable. So the first one is input assistant. The user should be able to help to avoid the mistakes. For example, when the user is filling a form, there should be proper guidelines provided. In the form and there should be proper error messages shown that the user is not submitting a form with error. So that is input assistant. The second thing is focus. So make sure that you add a clear and distinguishable visual indication to understand where the current focuses. It can be either a border color or a background color, but it should be clearly visible even in gray scale so that the user can understand where the focus is. So this is understandable. And now we'll move on to the last principle of WCAG that is robust. Robust means that the website should be built using technologies that are widely supported and are accurately or properly interpreted using assistive technologies. So the first thing is first guidelines or the only guideline under robust is compatible. That means that the content or the website should support current and future tool. When we create a website, it should support current version of all the browser, a few previous version of all the browsers and a few future version of all the browser. Make sure that your website is responsive and it support all the resolution. So that is robust. So this is perceivable, operable, understandable and robust. These are the four principles of WCAG. Now we'll move on to the conformance level or success criteria which I described before. So the first one is level A. Level A is the basic accessibility criteria. This means adding the proper or correct semantic architecture or using a button for button and not creating a button after a dip. So that is a level A. And level A is a level AA or mid range is an advanced accessibility feature. This include adding text alternative for non-text content or maintaining a proper color contrast ratio and et cetera. So level AA is the recommended one or your website should be at least level AA compliant to say that your website is accessible. Now we'll move on to level AA, that is the highest. It is really good to have your website to be level AA compliant, but it is really a little difficult to implement all the criteria. For example, in level AA, we have the sign language interpretations. So for any pre-recorded video content, so we have to add the sign language interpretation so that the user can understand what is in the content. So that is the conformance level. This is a wrap of WCAG. Now we'll move on to assistive technologies. So people who are differently able use assistive technologies to navigate through the application or use the application. So assistive technology can be any device, software or equipment that help the people who are differently able to perform tasks. The different assistive technologies includes screen readers, voice recognition, word prediction, screen magnifier, bookmarks and history and so on. I'll show you how a screen reader works at the end of the presentation. Now let's move on to accessibility-rich internet application. Accessibility-rich internet application are a set of attributes that are used to enhance the accessibility of an application. There are three attributes under area. They are roles, states and properties. First one, roles. Roles are used to define the purpose and meaning of element which are not natively HTML elements or are HTML elements but are not properly supported by the browsers. For example, if we need to create a tab list for our website, that is not a native element but still we have to create it. So we create it using button and then how the assistive technology or screen reader understand that this is a tab and not a button. For this we use a role. For roles, we have added roles tab and tab list so the screen reader will read the tab when asset tab and not a button. This is why we use the roles. Now we'll use the states. States are used to describe the current state of an application. Here in the tab list, we have added area selected as true for one and area selected as false for a few. Sorry. So here when the screen reader reads it, it can understand the first tab is selected or tab one is selected and the others are not selected. There are multiple attributes for state like area disabled, area hidden and so on. Now we'll move on to properties. Properties are also used to enhance the accessibility of an application. For example, area label. Here in this case, there is a button and there is no text for this button. There is only an image or icon is added for this button. So when the screen reader reads it, it will just read as button and it won't read any name. So the user won't be able to understand what's the purpose of this button. So I have added the area label as search. So that the screen reader will read as search, excuse me. Here the screen reader will read it as a search button. That's all about the area attribute which are used to enhance the accessibility of an application. Now we'll move on to design system. So I mentioned before that we can create and access the applications from this scratch even if we are not a specialized developer. So there are design system. Design system is a collection of components which we can use to create accessible application. So there are multiple design systems available in the market like Google Material Design or IBM Design Language and so on. So here in Red Hat we use the pattern flight design system. So if we are creating a website with accessible component, the whole website in turn will become accessible. So pattern flight is an open source design system managed by Red Hat. Now we can see a small demo of pattern flight design system. So this is the pattern flight design system and it is managed by Red Hat. So we have different components, then charts, layouts and everything inside it. As I mentioned this is an open source design system. Now we can go to the accessibility feature of this one. So here everything about accessibility is clearly mentioned and you can have a look at the features under this. Now we'll move on to the components inside this. There are a lot of components. This is an accordion like almost all the components which we use are there in this design system. For each component there is a react version, HTML version, HTML demos, design guidelines and accessibility. Everything is detailed described that you can understand how this component works. And that's about the components and now we'll move on to the charts. These are all the components which are available. You can have a look. So this is patternflight.org. You can have a look at the design system and there are different charts available and all of these components are accessible. You can easily use it. And there are multiple layouts which are used to create the layout of an application, like gallery, grid, flex and so on. Now as I mentioned, patternflight is an open source design system so you can contribute. There is a GitHub link also provided. If you are interested, you can contribute to patternflight. Now we'll understand what an accessible application should offer. We now know why should we create accessible application? How can we create it? And now we should understand what should it offer. So here I've taken the customer portal of Red Hat which is access.redhat.com and I'll show you how this is an accessible application and how this page responds to keyboard accessibility, keyboard navigation, how what is the light of score of this page and how the page responds in gray scale and how a screen reader reads the page. Let's have a look. So this is how a keyboard navigation is happening with the website. You can see the keyboard navigation happened using tab key, arrow keys, enter key and so on. So from the top, the keyboard navigation is going and it will come down as we navigate through the tab key and if we use enter key, it will select that particular button. It will see, you can see the visual, focus visual indicator as well. It is clearly visible and this is how keyboard accessibility should work in an accessible application. It should be able to completely navigate using the keyboard. Now I'll show the Lighthouse report. If you do not know, Lighthouse is a depth tool which we can understand how, what is the accessibility score of any application. So this is accessibility score of access.redhat.com and for a good accessibility application, accessible application, it should be at least 85 and we should have, we know we should try to make it at least 90 so that it has the pages really accessible and this sex even in lower resolution, like this is like a complete score of the application. So 94 is accessibility score of access.redhat.com or the customer portal of Red Hat and this is a pretty good and the application is accessible. Now we'll understand how this application is behaving in grayscale. So the users who are color blind or they are having low vision may see the application in a black and red view. So the application should be clearly visible in grayscale and even the visual focus indicator should be visible in grayscale and it should be completely readable. So this is how it is looking in grayscale. Here I have used Chrome extension to convert the space to grayscale and it is really easy to do that and you can check like how your application is looking in grayscale. Next one is how screen reader reads the application. I have used, so this might not, yeah, yes, yes. Yeah, there are different type of screen readers available. I have used Mac voice over and you can adjust the speed and everything. So there is time restriction so I cannot show in detail. Yeah, and for some of you this might not make sense like why we should use it. So if you are having that just close your eyes and try to use any application and then you'll understand the importance of screen readers or any SDA technology. So now we understand why to create accessible application, how to create using guidelines in accessibility enhancement and then design system and what should an accessible application offer. Now let's move on to the Q and A. Any questions? Yes? Yeah, right, the tool which I use is Lighthouse if you are not available that is a Chrome DevTool. In that we can find the accessibility score of an application and for some icons or if we are using some button and all there may be it is showing some unwanted error. If we are using some component from external library it'll have everything to be make it accessible but still Chrome can show that it is the score to be low. That's why it's showing us 94 and if your application is having some issue it will list all the errors. So if we are having time then I can show a demo at the end. Like how it is. Yeah, I can show a demo at the end. Before that any other questions? Yes? Yes, actually I have used Chrome Lighthouse like what he mentioned there are multiple tools available there are a lot of tools available. Okay, so he was mentioning like there are other extensions which are available in Chrome which we can use to see the monocombition of the application, right? There are other tools which can be used to understand the accessibility of an application. Yes, there are other tools available like acts, tools and everything. You can use it as per your convenience. Any other questions? Yeah? I suggest maybe that you are emphasizing very much a high tech approach. And the low tech approach can be not only useful but easier. Yeah. For example, one of the things I noticed in the past when we have been from accessibility is I make sure they are using a desktop PC for all that stuff. Yeah. And unplug them right away. Yeah. Unplug the mouse. Yeah. Now today, don't we? But only with the keyboard. Great. With Windows this is perfectly possible. It's very, very good. The Mac is possible but you have to learn a whole new user interface. With Linux it's very cool. Although it's improved. But this costs nothing whatsoever. And it's very simple. And within half an hour to an hour most developers are really going, oh my God, I have no idea. Windows itself, navigating the operating system is quite easy once you have a few strokes. But web is terrible. Tap, tap, tap, tap, tap, tap, ship, ship, ship, ship, ship, ship. Dammit. Tap, tap, tap, tap. But the next step after that is to get somebody on your desktop to get used to the screen reader on Pokemon. Yeah. This is for advanced stuff. But you know, you can take a few days and you are sort of giving an able-bodied person a disability temporarily. Yeah. The insight you gain from this experience will last for months to years. And you can teach this. Not by adding new tools, just getting scores. But by taking away tools that they are so used to using they don't think that. It's a very useful and simple technique which I really recommend to anybody. Particularly just unplug your mouse and learn to use your computer to keep one alone. GNOME is quite poor at this. Although I recently was speaking to a developer of Red Hat that hired to improve this. Windows actually remains the state of the art of this. And most of the flying technique I know of Windows. All in excess tops and all in excess could really learn from a very important set of lessons when you look at things you can add to improve it. The things you can take away because that requires no gun with and no expenditure alone. Right. Thank you, sir. And what he said is really right. I haven't have anyone tried with accessibility. Yeah, yes. So she was asking like if I have any experience in mingling with people who are definitely able and how they interact. So I do not have any direct accessibility but I have worked on a lot of accessibility issues which came after usability testing. And I have fixed a lot of issues with it. So I have that experience but I never interacted with a customer directly. And like what he said is really correct with the website having moving the keyboard is little difficult. But the thing which we should keep in mind is HTML by default is accessible. All the HTML components are accessible. We make it inaccessible by creating custom components and removing its, you know, you know, genuinity. So we make it inaccessible. So make sure that whenever we use a component use it directly. And any other questions? Okay. Now can you show a demo of how Lighthouse is working? Yeah, okay. Okay, yes. Okay, so this is a customer portal of Red Hat and I will show you the accessibility score and how it is calculating. So we need to go to inspect. And then we can see the DevTools and here we have Lighthouse. And in the Lighthouse we have multiple comments, accessibility, best practices and everything. Now here I am checking the accessibility only and it will calculate the score and it will show all the issues if there are any issues. And you can find it in a detail way. Yes, this is accessibility of a customer portal of Red Hat. See, they are saying that these few tabs are missing the roles. That is why it is showing that like that fix point is reduced from this. Like now I will show another example of Google Chrome or Google.com. So this is Google.com and Google is supposed to have Google is accessible and we can check the Lighthouse score. See here for Google.com it is 89. This means that Google is accessible, we know that. So there are some things even the Lighthouse can show error like it may reduce the score unwarrantedly. So go through the report and if you can correct anything, correct it. And always make sure to make it above 90. That is a really good thing to follow. And now if you are having any more questions, please feel free to reach out to me through my LinkedIn or you can probably gmail me. Please feel free to reach out. Then in the application, in the presentation you may just use and these are from FreePick. If you want to use it, you can use it. It is a free website where we can get good pictures. And these are the references. Most of the content is taken from w3.org and WebAIM. So you can go through these reference link as well. Thank you so much.