Hello everyone. So welcome to Conf fourty two. And today we will talk about the accessibility in Android and we will see how we can implementing it and how we can test. But before deep dive into the concepts and slides, I would like to introduce myself. My name is Nav, I'm from Montreal. I'm software engineer at Manulife, also GDG organizer at GDG Montreal and Google developer expert for Android. And also I write medium articles. You can find me on different social channels via my handle which is now crazy dad. So stay in touch there and if you have any questions you can just ask me on any of the social channels like Twitter or LinkedIn, wherever you feel comfortable. So let's get started with the today's topic. The first thing is what is accessibility and why it's important. So when we talk about the accessibility, it's not just about the people, those who have a disability, it's actually extending your reach of your applications, how user can interact with your applications, like providing more than one source, more than one option to the end user. There is not just a one single source that user can use to use your application, for example, just a touch. So in general terms, we can say that accessibility is to making sure that everyone who is having any kind of disabilities, like maybe having a colorblindness or they have any other physical impairments, to make sure that they can also access applications. We consider this topic as we talk about this and we will see how we can make our applications accessible for those people who have these kind of problems or situations. So we will see now the impact of accessibility. So the first thing is, as I earlier told you, it's not just about supporting the people who, those who have disability. It also helps to increase your application reach. So according to the World bank, it's like 15% of the world population, they have some sort of disabilities. So imagine like if you provide a sport for accessibility in your applications, like your userinterface are accessible, then you will also code that huge users user base which you might didn't consider before. The second thing is the apps versatility. So it's basically providing more base, how user can interact with those applications. And as I already told, it's not just about disability, it also covers the versatility part of your application. So now we will see how Android enables accessibility. So we know the general definition of accessibility and why it's important. And if we enable the accessibility in our applications, it also helps the people, those who don't actually have any kind of disability issues. So one of the main ways how Android enables accessibility is by allowing users to hear the spoken feeder. So whatever is like for example if you open any application, so whatever the content is on the screen, with the help of the tools like talk back or speech recognition screen readers, Android will speak for you like whatever the content is currently visible on the screen. There are other ways but that was the major way like the spoken feedback and mostly used so far as far as I have seen that and I have also tested with those tools and they are worked pretty well. So now we will see how we can make our applications more accessible and to make sure that there is no any issues with the user interfaces. The first thing is the task flows. So this is not basically the designing of your userinterface, it's basically the process of completing one particular task in your application. For example forbid password or reset password. And we need to define the very well defined clear task flows so that user can easily able to find those steps and easily able to navigate using those steps. For example, if they want to reset their password, it might be directly visible under the menu. But if it's under five steps under the hood like you first go to the drawer, then you select some options like settings, then you go to the profile, then you go to those kind of options like there are five, six steps. Then user might feel not comfortable using your application and they might just leave your application and also give you a bad rating on App Store. So whenever you define figure out the tasks, important tasks in your application and then make sure that you have the minimal navigation steps so that user can easily perform those tasks without wasting too much time. The second is the action target size. So sometimes you might see like the applications, they have a fancy design. But the issue is with those fancy designs that they didn't cover the clickable size like the touch target size of those particular things. Like if you designed any custom view and you set it, let's say you would write to 2020 DP. That means it looks like very little icon on your application and when user tries to perform click on that, it will be really hard or challenging for the end user. So the thing is like how big? So if you know that the material design team, they provided the guidelines for Android design, not just for Android UI designing, UI development, but also for our iOS. So the minimum test target size should be like 48 tapes. So whenever you design your custom views or any other views, try to make sure that if there is a clickable action, you need to make sure that they are having the minimum touch target size. Most of the elements, for example image buttons or buttons, they already have that minimum touch target size defined. So you don't need to worry about in that case if you are using the material compose in your application. But if you are used as I told you, if you are developing something custom, make sure that those views of those compose on the interface are accessible by the end user. Next one is the labeling of interface controls. Sometimes we design like sometimes we have components in our application or in our user interface which is like just for decorative purposes like for images. And sometimes we are also using images for providing some sort of information or using images for performing some actions. So in that case try to make sure that you add the labels to those images so that when user using the tools like talk back or screen readers, they will understand what actually that particular component means or what actually action that particular component is associated to. So that is the labeling for your interfaces. I will cover in the later part how we can add labels to the UI compose and the fourth one is enabling the focus based navigation. So if your user they are using tools or input sources like dpads or craft balls or keyboards, then make sure that you also provide the support for the purpose based navigation. That means if they are using arrows like move up left down right. So try to define your navigation by default, how XML layout is processed by the readers or the screen readers of the top right is like the order of how you have defined the elements in your XML. So if you have four elements they will be ordered like 1234. So if you go to that using that bottom like that down direction, so it will be like going from one to three, four. But if you have some sort of custom navigation then you need to make sure that it will be properly followed, properly defined in your XML. So that when user tries to use these kind of tools like keywords or dpads, the navigation is working as expected. So those are the basic parts of the navigation or accessibility or what are the important concepts that we need to be taken care when we are developing. And now we will see some little implementation like some properties that you can add to your XML components, for example to image view for your minimum size, those kind of properties. We will see how we can add those properties to our XML components to make sure that our application is accessible for everyone. It so the first thing is the image button here. But as I told you before, the material compose will by default have the minimum touch target size defined for all the components that are clickable. For example, here is the image button in this example I have added the third line. If you see it's Android content description that is for the label. So if you miss the content description for your decor, if you are using the images only for decorating purposes, you can omit this and you can add the property called important food accessibility and just set it to know. But if your image is for some sort of action then you must add a content description and that you can refer to the string resources. And here it's the image button but it would be if the content description make more sense when you are using the image views. And now the next example is the text view. And here I have added the two properties. First one is the foxable. So foxable means like if when user is using any tools like screen readers this compose should be processed or not by that tool. So setting it to focusable false. That means the talkback or screen reader will skip this. And the next property is the screen reader focusable and it's only available since Android version P. So that's why I added the last line which says tools target APiP just to ignore the warnings in your XML designs when you're developing your application. And on the next example is the heading. So sometimes if you see in the web navigation, like in the web websites like we have the headings and paragraphs, headings and paragraphs automated to those headings. So if you have some sort of designs in your application, like sometimes we have terms and conditions that have like we have heading and then we have a long long paragraphs underneath that. And then we have again some sort of headings. So if you want to process heading based, if you want to score heading based navigation, so user can move easily between those components, you can add the property called accessibility heading and it's only available since Android version P. So here is the navigation, the sample of the focus based navigation. So there are a couple of properties that you can add to your components as I told you, like by default tools they process your components as they already in the xml. So if you see here it's there four. So it will be going from text view hello world, hello World two hello world three and then the image. But if you want to do something custom, you can add two properties called like next focus forward, next focus left, right, I will show you later in the Android studio. What are the other options available? But here I only added the next focus forward. So from the first text view like tv hello World, it will go to the third text view and then it go back to the second text view and from there it will go to the image view. And if you see in the last image view tag, I added the content description and set it to a null. This is also other option if you don't want to set important for accessibility to know your image views and what it tells to the tools or to the accessibility related tools like talk about that. This image is only for decorative purpose so it will not be processed by the accessibility like those tools. On the right hand side I have the example for labeling your components. So this is a very old example I can say because if you are familiar with the material design, they have new components like text input layout where you can add labels to that compose and that will be behaving as a label for those. But if you want to add up, if you are still having some old code bases where you have added text in your layout files, you can attach the labels to those edit text using the text views and set the property label for your text view. So in this case if you see I have username entry and then I set the label for that edit text using the username label text view and then just defining the id of my edit text. The next example is for accessibility library and it's very important one I can say. So some of most. Sometimes if you're familiar, let's say for the login flow, when login fails we show random message, right? Like a message which says like login failed or you have entered wrong credentials, whatever. So in that case that error message is not always visible on screen, right? It's like a conditional. So if that condition is true, then we show that message. So here using that accessibility live vision property, what we are telling to the tool like topic that how that tools is going to process that particular view. In this case, which is text view. And there are three property like three ways it is assertive, non purple assertive means like if at particular given time when this particular view comes or shows up on the screen, talkback will stop whatever it's processing and it will process this particular view immediately. And none is the default behavior. And the polite one is like whatever is the tools processing. Now just finish that and then after that that will process this particular compose. And the next example is about grouping of layer components. So sometimes if you see for example, we have a list of items. For example, let's say we have a list of contacts and in each item we have a person's name, last name, there might be a date of birth, or maybe their sex or gender, whatever different properties are there and we don't want to process all those items like one by one by accessibility tools or the screen reader tools. So in that case we can group them together using the property called screen reader foxable or adding the flexible to the parent tag of those compose. So in this case I have relative layout that I would not recommend you guys to use. So in your case it might be constraint layout or it might be linear layout or if you are using compose then it might be something else. So you can add the flexible tag to the parent. So in this case I have added to the relative layout. So what it basically informs the tool or informs to the accessibility related tools that all the compose of this particular tag, like this particular route view will be processed as a one group. So if you have ten components in this case, in this example I have two text views. So those two will be processed together and they will be treated as a one component. And it's very helpful when we have list items so that user can easily understand what that full item means rather than going one by one like first name, last name and if there are five compose, it will be not a good experience for the end user. So those are some of the properties that you can add to your XML layouts. So now we will see how we can test accessibility of our application. Is there automation available? We have espresso for UI testing and agent for unit testing. Is there tools or ways for doing that? And then we will see what are the manual tool or the analysis tools that we can use to make sure that our application is accessible for everyone. Manual testing is like interacting with your application using the accessibility services. So for example you have developers just finish their one task and they hand over to the testers. Or if you are developer and you are going to test all these things, then you might just turn on the talkback and then process screen by screen of your application and see if there is any issues which is like a manual testing of your application and then the testing with analysis tools. There are various tools being talkback is kind of a manual and analysis that you can do more like a manual thing. But there is a very good tool which is called accessibility scanner and it's freely available in place so that you can install it to your device. And then from there you can scan the issues. If your layouts having any issues, like if there is any color contrast issues, or if there is any touch target size issues, or if there is any issues related to the accessibility, you will be able to catch those using that tools. I will show you the sample later on after the slides. And then yes, there is a way for adding the accessibility tests in your UI test. So if you have UI tests, there is only a single line of code that you need to add and there is one dependency that you need to add to your build file and you will be good to go and your old test will be integrated with accessibility test or checks. And if there is any issues your test will fail and you can easily figure out there. Also like how you can test your application accessibility and then there is a user testing like just hand over your application to real people and then see how they interact with your application and if they found any issues, you can work on those issues before publishing your application. The last one is the pre launch report. It's very important and it's also a fairly available before we publish our application, there is a pre launch report which contains lot of information about the application and then there is a portion which is related to the accessibility issues that you can find which is also early stage or it can be like a last step I guess before you launching your application. So you can stop there and see if there are any important issues or showstoppers that you need to fix before actually release your application. So here is the code sample of adding the accessibility checks to your espresso test. So if this code is written in Cogn wave. So in the left side I would prefer to use this one because this is the more concise one and on the left side one is more concise. In the right side I have added this is also enabling the accessibility checks. But there is also additional properties that you can add on to that accessibility checks. So when you say enable the checks and set run checks from root view set to true, that means it will process the full UI. So if you have only single test, let's say in your UI test, like you're just testing one label in your application and you are not testing the full UI. In that case it's really helpful that if there is any issues, let's say you have ten components, if there is any issues related to the accessibility found in those compose, your test will fail and you will be able to see in the loads like what went wrong. And then there is also other properties that you can set on top of accessibility checks. Like if you want to suppress some kind of results, like you don't want to fail your test or you don't care about some views in your application or some properties. So if you see in the right side, I added a set suppressing result matches and I set that if there is any text contrast issue, like if there is a color contrast issue just associated to that particular given id which is like text to be changed, can be any id of your component, just ignore that and just continue with the test. So these are the basics like how you can implement accessibility for the XML and how you can add the tests using the espresso. Now I will show you some demo like the real code and how we can use the tools that I show you earlier or explained you earlier in the slides. So now if you see my screen, I have Android studio opened and I have a real device mirror to my MacBook which is pixel. So let's first open. If you see on the screen here it's accessibility scanner. If you open this application and you will see if there are any issues that are earlier found, if you see the histories there, then there is a settings button that you can see the threshold about. It's all about basically application and you can find this application on Play store. So once that application is installed, so you will see this blue check like the tick on your mobile screen. So if you want to test any application, for example I have this sample created for this top. So I have these four or five components. So these two are using, I have used the old XML compose, like this is the image and this is the text view and then these are the compose components like the text, whatever different components in the code which I will show you later. So if you want to test using the accessibility scanner, you just click on this, you will see two options like record, you want to record this process or you want to take a snapshot. So I will go with snapshot. Now if you see it highlights, there are three issues with the three components. So you can see there are a couple of options like if you want to share this report with your, let's say if you are tester or if you want to share this with your team lead or other team members, you can also share this report. Or if you want to go through these compose. Like what are the issues? If you see here, there is a details like if there is a color contrast issue, there is a color contrast issue for this component and if you click it will take you there. So this component is having this issue. And if you see if you want to read it says like contrast ratio, current ratio is this one. Foreground color is this one. Background color is this one suggested, is this one. So this is the standard provided by the material design guidelines for accessibility. For the color contrast ratios for your text color and background color of your text. So this is how you can use the accessibility scanner tool in your applications and same for let me find out talk back. Also it's still under the accessibility if you see the screen readers accessibility scanner. So there is a talkback under the accessibility menu and you can turn it on and just go through your application and see if there are any issues. So these are how you can use these tools and they are freely available. The talkback is default shipped with most of the Android phones operating system and then scanner you can install. So let's see the test that I have written for my code. So first I will show you the code. So if you see the code I think it's visible. Let me make it a little bit larger so you can see this. So this is my main activity and there are some experimental APIs that I'm using. So if you see here I have used the compose and then I have compose code here I will not cover the compose accessibility but I have added and you can see here how you can add the accessibility to your compose compose like using the content description for your icon and using the semantics. And then there are different properties that you can add to the compose. Like if you want to set the foxable focus target, if you want to customize the navigation in compose there is a property like focus order and then you can define that. And then you need to define the focus requesters so that you can attach these to your composable functions or composable components. So if you want to go to second then you just say like when this dot down from this image, when the user press the downwards arrow, go to the second focus request and it will go to that second which is where you have attached this one. So in this case I have attached this to this text. So it will go to this text. So these are a couple of things that how you can add accessibility. This code is already posted on GitHub. You can check and see how you can do the accessibility in compose. So for example live region like how you added before in XML. Now there is a semantics and then it will have these properties like heading. If you want to process this text to be processed as a heading, you can add this heading. If you want to set the live region you can set that again focus order and content description for the other components. So this is in the compose, this is just some properties. And now I will show you the activity main which is XML way of doing things. So I have this image view and if you see there it's highlighted and if you see here what it says is like set content description so you will get the length warning about this. Like you need to set the content description for this. So I have already added just for you to showcase how it looks like without that. So if I add the content description that error or that warning goes away. So other cool thing is about the latest Android studio. I think since 4.0 or I'm not sure about exact version you will get a warnings during a development phase. Like if there is any issues. For example if you see before I told you the scanner shows the color contrast issue for this. If you see here it says that we have like two warnings and one error and one error shows that the source is like this text view, it has a color issues, color contrast issues. So either you can fix this or you can ignore this. So if you want to fix this it change that and if you see that error it goes away. So this is some of the cool features that are integrated within the develop IDE so that you can spore the accessibility within your application during the early phases of your application development when you are actually playing with the XML code. Next is the accessibility testing using the espresso. So I have espresso test here. So what I did is I could just enable this. So I just set the run checks from root view to true and this is from the espresso dependency that you need to add for accessibility checks. So this is from this library and if I show you the build file here, here is the dependency for this one. So if you pass accessibility you just search it and you will find it there. And once you add the checks for true and set it to true. And if I run this test as you see it starts running and we will see the results because we fixed that color contrast issue and we added the content description. So I think no test will fail. So both the tests are failed and I think there are still accessibility issues. So if you see the first test is failed and you see there is a one accessibility issue. So it says that there is Android compose view and it's not clickable. And if you see here, this item may not have a label readable by screen readers. So there is some views that still missing the content description or not clickable and your test will fail. So this is how you can add like a one line of code which will helps you to find out the issues related to the accessibility in your application. So this is some basics of how you can have accessibility related properties in your XML files like Screen reader Foxable foxable. Then next, focus forward. And if you see other options, there are a couple of other options like next focus down, focus left, focus right, focus up so you can add those properties as per your requirements. So that's all for this talk, and I hope you learned something new. Feel free to contact me on different channels as I show you before, whether it's LinkedIn or Twitter medium or GitHub, wherever you feel comfortable. And here are some of the references to some of the resources that you can follow to learn more about accessibility in Android. So I will share the slides. So thanks for your time and have a great day. Thank you everyone.