Easy Android accessibility – Android Conference Talks
hey there I'm Lila and I'm shaylen and this is an introductory talk about the basics of Android accessibility here is our roadmap we're going to start by defining accessibility and its importance that will introduce some accessibility services so that you know the different ways that your app can be used will then demo solving common accessibility problems while leveraging Android accessibility tooling and finally we'll talk about accessibility testing strategies now if you want to skip around we've linked to different sections of this talk below so what is accessibility simply put accessibility is about building things that everyone can use for Android
developers it is about making apps that can be used by every user regardless of how they interact with the device a good place to start when thinking about accessibility is by looking at some of the assumptions we make about our users so take me as an example I'm an app developer I can see my phone screen reasonably well and I can touch the screen with reasonable precision but there are a lot of users who may not be able to see the screen or may not see it very well and they may not be able to touch the screen or may not be able to do so with good precision the thing is if I go through the trouble of building an app I want every one of those users to be able to use my app it's not enough that I can just use it accessibility needs come in many different forms and include people who are deaf or hard of hearing those who have motor impairments those with cognitive disabilities that may impede learning or are blind or visually impaired the World Health Organization tells us that one in seven users worldwide experience some form of disability that's over 1 million people who have accessibility needs every day in order to live their lives and it actually goes well beyond those 1 billion everyone at some point has had an experience where something was not sufficiently accessible this can be temporary say you cannot use your hands because of a surgery or this can be situational for example when you're looking at a screen with poor contrast in bright outdoor light so accessibility is not only a moral imperative it is a tremendous business opportunity there are a lot of users who have some kind of disability and they would love to use your app make in-app purchases etc so let's talk about how these users interact with your app they use accessibility services these are long-running privilege services that provide different ways for users with disabilities to interact with your app let's look at some commonly used accessibility services talkback is a Google screen reader included on many Android devices talkback gives users spoken feedback so that they can use their devices without needing to look at the screen users discover content by moving the fingers across the screen and as a view is discovered talkback announces it and users have easy shortcuts for performing gestures like clicking long pressing etc brailleback is another common option for blind or visually impaired users with Braille Mac users can connect a refreshable Braille display to an Android device by a Bluetooth brailleback works with talkback to provide a combined speech and Braille experience switch access that users interact with an android device using one or more switches instead of the touchscreen switch access can be helpful for users with dexterity impairments that prevent them from interacting directly with the Android device switch access scans the items on your screen highlighting each item in turn until the user makes a selection the good news is that you can serve all these different users by writing just one version of your app the Android framework takes care of providing information needed by different accessibility services to properly render your app so let's talk about the interaction model when you're interacting with your phone you can divide all of those interactions as your presenting information to you like text buttons and images and then you as the user acting on the phone like pressing those buttons and swiping around your actions cause more information to be presented and in response the cycle continues users with accessibility needs benefit from having that information presented in multiple ways they also benefit from having multiple ways to interact with your app for example a motor impaired user might have difficulty interacting with your app if drag and drop is the only way to use your app and a visually impaired user will have difficulty understanding the information that's presented to them if it's only available as written text so the accessibility services help solve this problem for you they provide alternate ways to present information to users and then to let those same users interact with your app the end result is that if you have a visually impaired user you don't need to write a screen reader for your app there's already one available via a accessibility service called talkback now you don't directly use each accessibility service instead you just write your app and then the android framework is what communicates with these accessibility services most of the time if you're using standard views like text views and buttons they're built to work with the framework to support accessibility out of the box this means that the majority of the time they will present information and allow users to perform actions using their accessibility service of choice here's an example with talkback as you're using talkback you move to different elements on the screen and then there's some text that is read to you for this switch talkback will read also vibrate for calls off switch DoubleTap to activate talkback gives you the label the state of the control the control type and the action to interact with it and this is presented in a standardized way that a talkback user is used to as a user I can double tap anywhere on the screen that switch will then flip and talkback will reply on for standard widgets like this switch all this functionality comes for free now there are some situations where the framework can't just automatically tell accessibility surfaces like talkback what to say images are a prime example of this the framework won't know how to interpret these three lines and explain this fab to the user so it's gonna say something unhelpful like I'm late button so sometimes you need to fill the gaps like this for the accessibility framework and to do that you use the accessibility API s here are some additional examples of what you might use these api's you might want to tell the accessibility framework that there are clickable links in your spam or that a view group should be treated as an alert window or in the switch example that I just gave you might want to say double tap to toggle when you press the switch instead of saying the standard activate for all of those situations you'd use the accessibility API as to make those changes now things start getting a little bit complicated when you stray from the standard views implementing custom views could be its own video but there are a couple good rules of thumb you should be leveraging accessibility code that's already been written for you so for example if you extend from button you're gonna get all of these accessibility features from view text view and button including handling of the label state control type and action this now isn't the case if you were to instead extend from view so try to make use of what's already been built for you if you can in summary for most situations if you use standard components the android framework will take care of interacting with the accessibility services and what the framework needs more information you'll then provide that information using the accessibility API is to fill in those gaps now let's look at some common accessibility problems missing labels make it hard for screen reader users to know the purpose of your controls I mean unlabeled button isn't particularly useful as a label is it but that's what a screen reader like talkback announces if you don't provide a meaningful label touch targets that are too small can be challenging for users with the Xterra T issues or even for users who may have large hands or those who may be using your app while sitting in a bus or a car and poor contrast can make it pretty hard for many users to properly digest the content of your screen so now that you know about these common issues how do you find out if your app has these issues a pretty good place to start is with accessibility scanner which is a free that you can get from the Play Store accessibility scanner performs an audit of whatever is visible on the screen and makes suggestions for improving the apps accessibility it is super easy to use and you don't even need to be particularly technical to use it you can also share scanners reports by email or through Google Drive scanner can be run on any app and does not require any special code changes so let's try out accessibility scanner using an actual example I built a really really simple counter app it displays a numerical count with minus and plus controls to increment and decrement that count as it turns out there are some accessibility issues with this app let's use accessibility scanner to find out what they are after installing scanner you can find it in the accessibility screen under settings along with other accessibility services once you grant permission to use scanner you'll see a blue button which overlays any screen that you can navigate to you can move this button around and you can kick off an accessibility scan by simply tapping on this button now here's the counter app again with scanners floating blue button overlaid over it when you run the scanned scanner comes back with five suggestions let's see what they are scanner suggests improving the text contrast of the counter heading if you expand out the suggestion you can see more details about the contrast issue scanner gives you details about the foreground and the background colors and suggests a contrast ratio you should aim for generally speaking for larger text you should aim for a 3.
0 contrast ratio for smaller text a contrast ratio of 4.
5 is recommended the next suggestion scanner provides is that the minus button is missing a label you can fix this by adding a content description attribute providing a useful label for internationalisation reasons this should always be a localized string here are some more good practices for labeling when labeling editable views like edit text set the Android hint attribute if an element in your UI exists only for visual purposes set its Android content description to null and if your app supports only devices that run on Android 4.
1 API level 16 or higher you can instead set these purely decorative elements Android important for accessibility attribute to know the next suggestion is about the touchable area for the button scanner tells you that your button is 24 by 24 dips but you really should aim for at least 48 by 48 dips you can either make your icon bigger or you can expand the touchable area by adding padding or registering a touch delegate accessibility scanner is an indispensable tool for developers now let's now talk about pre dance reports pre launch reports are automatically generated when you upload an apk for release on the Play Store this is an automated testing solution which crawls apps on multiple physical devices and detects issues you can fix before your app reaches the end users it identifies crashes performance issues and a few other topics and it now includes accessibility pre launch reports can be found on the Google Play console you can see the list of issues identified in a report and you can fix those issues before launching your app issues are categorized clustered and ranked by severity this slide shows your detailed view for an issue found in a pre launch report you can see that this issue deals with incorrect contrast ratio and report suggests a way to improve the contrast the Left panel shows you other occurrences of the same underlying issue for each accessibility finding identified by a pre launch report the learn more link provides in-depth information for understanding and fixing the issue you're new to accessibility this is pretty useful and now let's talk about testing when you think about testing your apps accessibility you can divide tests up into four basic categories now Shadeland already mentioned testing with tools when he talked about scanner and pre-launch reports so I'm gonna start with automated testing behind the scenes both the accessibility scanner and the API is for automated accessibility testing use accessibility tests framework to run aka ATF specifically ATF powers the two main automated testing integrations with espresso and robolectric ATF is open source so you can just dive in and take a look at the code on github now it's a rules-based evaluation meaning that it's made up of a series of accessibility checks ATF can test for the three most common accessibility issues shaylen mentioned and much more here's just a few of the checks that it's running for you let's look at the espresso ATF integration the goal disintegration is to piggyback off of your existing expresso tests and to make them also test for accessibility issues this is done with basically just a single line of code so assuming you already have those espresso tests this is a very easy thing to add now that one line of code is accessibility checks not enable and you also need to add the dependency so maybe it's more like two lines of code now there's an Android X dependency and if you haven't migrated to Android X well you should do that right now but otherwise there's also a support Lib dependency okay so let's see what adding this line of code does for us so over here is a completely normal expresso test nothing has been added for accessibility specific testing here you're basically just clicking a button and then you're making sure that the counter view is incremented after that button click again this is a completely basic vanilla espresso test okay so let's say that you enable those accessibility tests by adding accessibility checks enable so now we go ahead and we're gonna run the test again this time ATF accessibility checks run note that in order for ATF to hook into these tests you must use a view action meaning a view action for the view actions class here we use a click action if instead you interact with the view instances in some other way like trying to do it directly this will actually bypass all those accessibility checks and it won't do anything for you so use a view action now if there are accessibility issues such as missing labels or maybe your touch targets are too small ATF will throw an exception and The Associated tests will fail this will proactively protect you against introducing accessibility issues into your app here you'd see that we unfortunately had two issues with that button and if you scroll over you'll see some information similar to the info that you got when you ran accessibility scanner about those issues and some recommendations for how to fix them now one important note by default ATF will only check the views that you perform view actions on which in this case means that ATF is only checking that button and not any of the other views of the test now if you want different test behavior you can configure your accessibility checks when do you run accessibility checks enable that returns an accessibility validator object meant for that configuration now this object can control test run behavior it lets you handle what happens when ATF finds an error let's look at a few specific examples you can use set run checks from route view to get more coverage by checking the entire view hierarchy what a view action is performed so for that previous example this would actually also check the counter view for accessibility issues okay so if I turn that one config setting on you can now see that instead of just catching those two issues that I saw before I'm now catching five issues by default if your espresso tests run into accessibility issues exceptions will be thrown anger tests will fail but you can use the accessibility validator to simply log the test failure instead to do that you can change set throw exceptions for errors to false now just be mindful that when you're doing this it's easy to forget to check your logs thorough any exception will get your attention which is why it's the default another option that you have if you don't want to turn off exceptions for all tests is to use the set suppressing result matcher this option allows you to suppress accessibility testing exceptions related to either certain views or certain ATF checks thus if you have a view or a check that just always fails you can temporarily suppress that error for example if you know a particular but with a contrast issue you could suppress contrast checks for that button using this code in general you want to be as specific as possible when disabling ATF checks so in summary using ATF is as simple as enabling accessibility checks and making sure to use view actions optionally you can configure how ATF runs using an accessibility validator ATF also has a robolectric integration and it's very similar you only need to add the add accessibility checks annotation to start leveraging your robo electric tests to run accessibility checks now let's talk about manual testing for accessibility which can catch issues not found by tools like scanner or through automated testing for example scanner or automated tests can find missing labels but they cannot check if the labels are meaningful that's where manual testing can help in this form of testing you test apps using accessibility services there are many accessibility services of course we recommend that at the very least you should test your app using talkback and switch access at Google we found that most successful app teams are those that adopt both automated and manual accessibility testing techniques as part of their development process let's first explore testing the talkback talkback exposes two common modes of navigation first linear navigation where a user performs swipe gestures to explore content on the screen and double tap anywhere to click on a view second explore by touch where a user drags a finger over the screen to discover content and once again the user double taps anywhere to perform a click users can perform common tasks like navigating to home or opening a notification by performing simple gestures explore the app a talkback and as you navigate check for the following are you able to reach every element by swiping and are you able to complete the main workflows of your app does the spoken feedback for each element can weigh its purpose appropriate our announcement succinct or are they needlessly verbose now let's look at testing with switch access you can find switch access on the accessibility screen under settings for testing you can configure the volume keys to scan the app and make selections i commonly program volume down to scan for elements and volume up to make a selection to not switch access and start testing your app specifically look for the following are you able to reach each and every element and are you able to complete the main workflows easily if you have text or other inputs can you add and edit content easily and our items highlighted only if you can perform actions of them user testing with actual users with accessibility needs is vitally important even if you test the app yourself you're never going to know exactly how a visually impaired user for example experiences your app unless you happen to be a visually impaired user find actual users sometimes you can leverage your network to do this you can also find testing agencies they're specific agencies that specialize in accessibility user testing now also pay attention to feedback from all sources if you do get reviews or issue reports about accessibility please don't ignore them apps work best where there is a comprehensive accessibility testing strategy you should be testing with tools throughout the development and release cycles you can use automated testing to identify common issues quickly unpress amit and with continuous integration you should then use manual testing to understand a user's actual experience and finally use user testing to solicit feedback from those with real accessibility needs to sum things up the biggest takeaways are first if you remember nothing else from this talk please pay attention to those three most common accessibility issues labels contrast issues and touch targets you can then use accessibility scanner and pre-lunch reports to help you find those issues you should try actually using some of the accessibility services yourself to get an understanding of how they work and accessibility testing via espresso and robolectric can be added with just one line of code thinking about accessibility can help improve your UI by making it simpler cleaner and less cluttered this helps all users not just users with disabilities now accessibility should be easy so if it's ever not please please please get in touch with us if you find bugs or your feature requests you can submit them via the issue tracker now if you liked this video there's tons more like it on this channel don't forget to Like and subscribe thanks for watching you.
Nhận xét
Đăng nhận xét