What's next? A practical introduction to accessibility on Android
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Munim, Ataul
A structured guide to building accessible apps on Android. This presentation will include practical checks and steps you can implement today and give you the confidence to know you're doing the best you can to support as many users as possible. The content will be familiar to beginner Android developers and we'll use a real-world app as an example to ensure we're covering non-trivial usecases.
 Hi, everyone. Welcome to this late, late session on Android accessibility. Thanks for coming. This talk is aimed at people who might have some knowledge about accessibility already. Maybe you've had some feedback from others about best practices, tips, and tricks. But now that you're looking for a structured approach and how you can actually start including this sort of thing in your apps, how you can begin and how you can move forward with real world examples. I've been doing accessibility on Android since 2015, starting on a newspaper app called The Times and Sunday Times. Since then, I've moved on to another product called Channel 4, which is similar to Arta in Berlin or some TV on demand app. And what's really nice is seeing over the last three years or four years, meet-up organizers and conference committees accepting and considering accessibility talks or talks about inclusive design. Like I think we had Mitchell in the front row yesterday speaking yesterday at the bar camp about accessibility, which is cool. And since around 2016, because of all this content, all this exposure, there's been lots more teaching content as well. So lots of more people with more speakers and more blog posts are introduced to accessibility, which is cool. So a few people took up this sort of accessibility mantle, championing inclusive design within their teams and companies. And while it's useful to have a single person or an enthusiastic supporter or expert around, having one person is not sustainable for their product, because you need the whole team on board. Like you can't fight against the current. Imagine if you get hit by a bus or something. And I think one of the things that we need to think, well, one of the things we need to address is that we're moving too quickly. Or we're producing content, which is shallow in our investigations or research. So you get lots of tips, lots of tricks, and best practices. But it's kind of overwhelming, because you don't know what to begin with. You don't know what to start with. And how you can move forward and actually make a difference in the experience for your users. So you get people who leave the talks and who read the blog posts. And they think, OK, accessibility is a good thing to do. But where do I start? There's no framework and no real context to apply changes. So I asked the community, what do they need? What's stopping you from implementing what you've already learned in your apps? And they replied. So I've got lots of varied responses. A few of the responses were surprising, because there was a lot more experience that I didn't expect. People were asking about advanced topics. Like, how can they integrate these accessibility checks with their continuous integration systems? Like, how can they prevent regressions from occurring after they've added support? Some were asking for tooling help. Like, is there anything that we could do to improve the automated testing? But the majority of people were asking for help on getting started. Something practical, like a guide, kind of like a migration of how you can take your app as it is now, assess it, and then move forward. But it's kind of a big task. What do you do first? You could do code samples, like the architecture blueprints. You have videos and guides, and how users with disabilities actually use Android. So you can see firsthand how your app is being used, or what the pain points are, do different people have different habits? Do different people have different patterns or preferences, even if they've been labeled with the same disability? And there should be some sort of addressing of trade-off between the design and developer effort to the actual returns on that investment. And how can you convince the business to spend time and money on it? So my goal for this year, so it's, I guess, halfway through the year. So this is a bit slow. But it's to answer this question, answer these questions, provide these sorts of guides and structured ways to move forward, answer questions, give feedback, and get feedback as well. So still understand what people are struggling with, produce samples and docks and tools to help testing. What I want is for people to feel confident to approaching inclusive design head-on. And my 15-minute goal, because I don't have a year, is to present as part of this effort. And I'll begin by explaining what I think accessibility is. If you have learned about accessibility before, could you give me a little nod or a hand in the air? Cool, says a lot of room. Just forget everything you've learned before. Not because it's wrong, not because I think I know better. But because I think it's nice if we all start from the same page, we all have a shared understanding of what we think an accessible app is and does. And for me, that means two things. Every single app does two things. One, it presents information to the user. And two, it provides a way for the user to interact with the app. And our job as developers, designers, product owners, assessors, et cetera, is to facilitate this for as many users as possible. And this facilitation for as many users as possible is what accessibility is. To do that, we need to know our app. So we need input from our product owners. We need input from our designers. Everything that you do needs to be done with intent. So any sort of information or action that you want to show to your users needs to be prioritized and sorted so you're not overloading the user with too much information. And since there's been requests for non-trivial examples, let's use YouTube as a real world example. So we'll highlight the things that YouTube does well, because I'm not using it as an example of things that aren't from well. But one of the cool things about using this app is that it uses a lot of the widgets that we use in our day-to-day. So it uses recycler views. It uses images. It uses text views, et cetera. But it also uses widgets that we don't necessarily encounter day-to-day, like video, which provides this app with affordances for other avenues to present information. We'll highlight things that does well, and we'll also look at the opportunities to approach some things differently. And then by the end, hopefully, we've got a set of actionable steps or checklist that you can work through. And we'll cover two topics, because I think now I've got 10 minutes left. But for me, these ones make the biggest impact. So they might seem simple or trivial, but in general, they're the things that are going to have the biggest returns for a lot of users. The first thing we're going to start to talk about is text. Text needs to be one thing only, and that's readable. If it's not readable, then it's their point having it on the screen. And it's our responsibility, as developers, as designers, as product owners, to ensure that readability. One of the hardest things that we have to do is design for dynamic content. So we don't know necessarily when we're getting strings from the API room locally how long it's going to be. Even for content that we do know, so stuff that we package inside the APK, translations, different screen sizes, it means that there is going to be varied lengths. So we can't know at design time. There's a few ways to solve this. You can use a fully responsive layout, which we've been introduced to from day one with dimension like wrap content. You could also truncate the text. You've probably tried doing this by adding ellipses if the text extends too far. Or you can have some sort of combination where you might display an abridged version of the text showing like a summary, but then have some affordance that takes the user to see the full length. And the YouTube app demonstrates all of these techniques. On the home screen, here we've got each of the item widths which match the device width. But the item height is unconstrained. Because the list is vertically scrollable, it means that the items can grow as large as needed. And so if the video titles are long or novel-like, it doesn't matter. The view is going to extend as much as needed. And the titles will just wrap. But there's also cases where width and height constraints are necessary, potentially because you're trying to maximize the amount of content that you're trying to fit on the screen. In these cases, where you've got fixed size views, it means that sometimes text needs to be ellipsoised. You can't fit as much text as you want inside. You can't extend the view. So you need to indicate that it's an intentional choice for you to ellipsoise or truncate the text. But this isn't enough. If this is the only place where you can read this text, then it's important that, well, one, we've lost sight of our original goal, which was to make text readable. So what can this ellipsoise mean? It doesn't need to be bad? No. Ellipsoise can serve as a subtle call to action, some sort of like a click here for the full story. So when you click on the text, the ellipsoise text in the video list, it takes you to the video detail, where you can expand or you can see the video titles in full. You can expand to see the descriptions as well. The descriptions. So I don't know how often people are surfing on YouTube, but people like to fill out the descriptions a lot. The platform is for video, but people like to write a lot. In this example, the user needs to click on the title to see expanded content. But it's not only the descriptions that are made visible. The subscriber and the views format changes. So things aren't abbreviated anymore. You can see things in long form content. But you still need to be careful. Even in the cases where you've got more space, remember to check for the cases where text might be unintentionally cut off. In this case, where we're ellipsoising the subscriber count, the information here is important, but not necessarily when you click through to the next page of the video details page. Here, maybe we could have done wrap content instead. And if you're lucky enough to have 5 million subscribers, then maybe it's OK for the subscribers where to be on the next line. And sometimes it's better to hide these elements entirely rather than to show them partially obscured. The good news is, if you can handle this sort of varying text length already, the next step is easy. The next step is about supporting different font scales. So you should use scale-dependent pixels, so SPs, where this unit is useful. The user is able to change the font scale at a system level, and our app should respect that. Doing this correctly, for me, is the biggest impact you can have in terms of supporting vision-impaired users. Because it means, well, for me, this is the easiest way your app can break. So you increase the text size because you can't read something from the normal reading distance, and then suddenly all the layouts break. You get ellipsoid text. You get overlapping text. Well, worst case scenario, you can't read stuff. Best case scenario, it looks ugly. And there's two parts of what this means for doing it correctly. First, use SPs instead of DPs so that the system can apply that size transformation for you. And secondly, make sure that as the text size increases, text size is in cutoff. So that whole last section I talked about. The user is not able to pick what ever size they like. In my testing, I found that there's four scaling factors, at least on the Pixel phones, which range from 0.8 to 1.3. Mitchell told me just before the talk that also the OEMs can change these or provide different options. So he's seeing it at 1.5. So the testing doesn't need to be to the extremes. You can test up to, for example, 1.5 or up to 2. And it's enough. To make that easier, the testing easier, we wrote a JUnit rule to help. So as part of your espresso tests, you might be using activity test rules. Activity test rules work in that when your espresso test starts running, your activity spins up. And then after your test finishes, it tears down. So what can we do? We can combine this. You can combine multiple test rules with a rule chain. And one of the rules that we created at Nevada was the font scale rule. So in this case, where the font scale rule wraps the activity test rule, the font size on the device will be changed to begin with. Then your activity will spin up. So it's already at the correct size. Then your test will run. The activity will tear down. And then the font size will be reset to the original value. This isn't so useful because it's kind of hard to detect when your layouts break. But if you combine it with other test rules, like the screenshot test rule, I think Facebook has one, for sure. There's other ones available. You can use it to speed up all the manual testing that you have to do. I'm going to skip past this next section about making your text color considerate. There's two main points to consider really. It's don't convey information with color only. Like provide some other affordance, like making it bold or underlined. And making sure that you test the color contrast ratio as well to make sure that whatever text or iconography that you have, it's distinct enough from the background to be readable. So in this case, you've got that gray background behind the play controls. So no matter what the image is behind, no matter what the video is, you can still see the controls. And a structured guide to accessibility on Android would be kind of incomplete without mentioning accessibility services. So an accessibility service, hands up, no one. Call. So maybe the one that you will be most familiar with is TalkBack. It's a software implementation of an assistive technology. It acts as a screen reader. So it's used by Vision and Pedge users. So they can read what content is on the screen. And it also acts as an interaction helper as well. So the users can use gestures, like swiping and double tapping to interact with the widgets on their phone. So it still does these two things that we mentioned at the beginning. It conveys information to the user, and it provides affordances for them to interact. So TalkBack's the most familiar one. With TalkBack, users can navigate through elements on the screen sequentially. Double tapping anywhere on the screen will send a click event to whatever's focused. When I was collecting feedback, someone asked what makes a good content description. A content description is a metadata that's assigned to the view. It is readable by any accessibility service. And TalkBack will use it as the spoken description for whatever view is focused. So what makes a good content description? A good content description describes what a view is and nothing more. So you don't necessarily need to say that it's a button or an image. You can describe it. I think Samsung tried to push really hard for all the buttons to be labeled as buttons, which is why you might see that in some of the Samsung apps, or maybe further. But now we've got usage hints. So it's enough to say that what the view represents. So here we've got YouTube and Search rather than YouTube logo and magnifying glass. But how do you describe these actions? So in this case, we've got a view group. Our view group here contains quite a bit of information. And it's not just individual views that need content descriptions. If you set the description on a complex view group, then it means that you're telling TalkBack explicitly what you want it to say. Otherwise, it's going to try and concatenate the description from the elements inside, which might be too verbose. So that's something that you need to talk to your product owner about and your designers about. How do you specify the action? If you're just describing what the view is, how do you say what happens when you interact with the view? So you can use usage hints. Use of hints are available from, I think, API 16, but you can customize them from API 21. These are, if a view is actionable, for example, if it's clickable or long clickable, TalkBack will read the description out loud, and then it will pause for a second and then follow by the hint. So in this case, it says double tap to play the video. By default, it will say double tap to activate or double tap and hold to long press. But these aren't helpful. So you can customize them. The way you do that is using accessibility delegates. You can add additional metadata about the view to the accessibility node info objects, where here we're specifying that the click action is associated with the play video label. Or if you're using Android KTX, you can use this extension function to set usage hints. And that's pretty much it. So if you're after a base level of support for TalkBack users, content descriptions, and use the chance. But we're not after a base level. We're looking to raise the bar. Since we saw that users navigate sequentially with touch base gestures, can we improve that? So imagine you've got a long list of items. The user's going to need to swipe a lot to get through each item. Instead of having three clickable areas per item, you can have one. This means that you only need a single gesture to navigate. But you can't just get rid of actions and reduce the functionality, because that's not making it accessible. That's making it less accessible. Instead, so when a user clicks on an item, we can display all of the actions in a dialog like a bottom sheet. Doing this across the app, wherever we're looking to simplify view groups, will lead to a consistent user experience for TalkBack users and also keyboard users or switch access users. You can, again, use the accessibility dialog if you want to expose these to the power users or for accessibility services. Here, you just need to override another method, unperform accessibility action, where you call back to your listener. To make it easier to implement this and the dialog stuff without duplicating code, you can use accessibility tools from the VodA. Here, we can use a menu resource to inflate a menu and then set that as your accessibility delegate. Finally, you can also add actions to the UI where necessary. So consider the video controls overlay, which usually disappears after a few seconds. If TalkBack is enabled, YouTube avoids the timed auto dismiss so you can change behavior. It adds an explicit dismiss button to the overlay so it stays on the screen until the user explicitly dismisses it. In addition, because the seek bar controls are fiddly to use with TalkBack, there's additional rewind and forward buttons available. So that was a really quick introduction to accessibility on Android and what you can do today to start influencing it in your app. There's stuff about making your text readable, making sure that your layout is responsive so that you're not cutting off content unintentionally, making sure that your text is scalable so that it respects the user's preferences, making sure that the colors are chosen considerably so that you're supporting users that have difficulty with low color contrast. And then finally with TalkBack users as well, making sure that you're improving the navigation and providing good content descriptions. If you have more questions around today and tomorrow, otherwise, Nevada, our hiring. Thank you. [? Thank you.?] Thank you, Attal. We have five minutes for questions. You have two microphones in the middle. Or you can ping me directly outside anywhere. Someone found my email somewhere, so they did that. That's OK as well. Cool, thank you. Thank you. Thank you.
 Hi, everyone.  Welcome to this late, late session on Android accessibility.  Thanks for coming.  This talk is aimed at people who might have some knowledge  about accessibility already.  Maybe you've had some feedback from others  about best practices, tips, and tricks.  But now that you're looking for a structured approach  and how you can actually start including  this sort of thing in your apps, how  you can begin and how you can move forward  with real world examples.  I've been doing accessibility on Android since 2015,  starting on a newspaper app called The Times and Sunday  Times.  Since then, I've moved on to another product  called Channel 4, which is similar to Arta in Berlin  or some TV on demand app.  And what's really nice is seeing over the last three years  or four years, meet-up organizers and conference  committees accepting and considering accessibility  talks or talks about inclusive design.  Like I think we had Mitchell in the front row yesterday  speaking yesterday at the bar camp about accessibility,  which is cool.  And since around 2016, because of all this content,  all this exposure, there's been lots more teaching content  as well.  So lots of more people with more speakers and more blog posts  are introduced to accessibility, which is cool.  So a few people took up this sort of accessibility mantle,  championing inclusive design within their teams and companies.  And while it's useful to have a single person  or an enthusiastic supporter or expert around,  having one person is not sustainable for their product,  because you need the whole team on board.  Like you can't fight against the current.  Imagine if you get hit by a bus or something.  And I think one of the things that we need to think,  well, one of the things we need to address  is that we're moving too quickly.  Or we're producing content, which is shallow in our investigations  or research.  So you get lots of tips, lots of tricks, and best practices.  But it's kind of overwhelming, because you  don't know what to begin with.  You don't know what to start with.  And how you can move forward and actually make a difference  in the experience for your users.  So you get people who leave the talks  and who read the blog posts.  And they think, OK, accessibility is a good thing to do.  But where do I start?  There's no framework and no real context to apply changes.  So I asked the community, what do they need?  What's stopping you from implementing  what you've already learned in your apps?  And they replied.  So I've got lots of varied responses.  A few of the responses were surprising,  because there was a lot more experience  that I didn't expect.  People were asking about advanced topics.  Like, how can they integrate these accessibility checks  with their continuous integration systems?  Like, how can they prevent regressions  from occurring after they've added support?  Some were asking for tooling help.  Like, is there anything that we could  do to improve the automated testing?  But the majority of people were asking for help  on getting started.  Something practical, like a guide,  kind of like a migration of how you can take your app as it is  now, assess it, and then move forward.  But it's kind of a big task.  What do you do first?  You could do code samples, like the architecture blueprints.  You have videos and guides, and how users with disabilities  actually use Android.  So you can see firsthand how your app is being used,  or what the pain points are, do different people  have different habits?  Do different people have different patterns or preferences,  even if they've been labeled with the same disability?  And there should be some sort of addressing of trade-off  between the design and developer effort  to the actual returns on that investment.  And how can you convince the business to spend time and money  on it?  So my goal for this year, so it's, I guess,  halfway through the year.  So this is a bit slow.  But it's to answer this question, answer these questions,  provide these sorts of guides and structured ways  to move forward, answer questions, give feedback,  and get feedback as well.  So still understand what people are struggling with,  produce samples and docks and tools to help testing.  What I want is for people to feel confident to approaching  inclusive design head-on.  And my 15-minute goal, because I don't have a year,  is to present as part of this effort.  And I'll begin by explaining what  I think accessibility is.  If you have learned about accessibility before,  could you give me a little nod or a hand in the air?  Cool, says a lot of room.  Just forget everything you've learned before.  Not because it's wrong, not because I think I know better.  But because I think it's nice if we all  start from the same page, we all have  a shared understanding of what we think an accessible app is  and does.  And for me, that means two things.  Every single app does two things.  One, it presents information to the user.  And two, it provides a way for the user to interact with the app.  And our job as developers, designers, product  owners, assessors, et cetera, is to facilitate this  for as many users as possible.  And this facilitation for as many users as possible  is what accessibility is.  To do that, we need to know our app.  So we need input from our product owners.  We need input from our designers.  Everything that you do needs to be done with intent.  So any sort of information or action  that you want to show to your users  needs to be prioritized and sorted  so you're not overloading the user with too much information.  And since there's been requests for non-trivial examples,  let's use YouTube as a real world example.  So we'll highlight the things that YouTube does well,  because I'm not using it as an example of things  that aren't from well.  But one of the cool things about using this app  is that it uses a lot of the widgets  that we use in our day-to-day.  So it uses recycler views.  It uses images.  It uses text views, et cetera.  But it also uses widgets that we don't necessarily  encounter day-to-day, like video, which provides this app  with affordances for other avenues to present information.  We'll highlight things that does well,  and we'll also look at the opportunities  to approach some things differently.  And then by the end, hopefully, we've  got a set of actionable steps or checklist  that you can work through.  And we'll cover two topics, because I think now  I've got 10 minutes left.  But for me, these ones make the biggest impact.  So they might seem simple or trivial,  but in general, they're the things  that are going to have the biggest returns for a lot of users.  The first thing we're going to start to talk about is text.  Text needs to be one thing only, and that's readable.  If it's not readable, then it's their point having it on the screen.  And it's our responsibility, as developers, as designers,  as product owners, to ensure that readability.  One of the hardest things that we have to do  is design for dynamic content.  So we don't know necessarily when we're  getting strings from the API room locally  how long it's going to be.  Even for content that we do know, so stuff  that we package inside the APK, translations,  different screen sizes, it means that there  is going to be varied lengths.  So we can't know at design time.  There's a few ways to solve this.  You can use a fully responsive layout, which we've  been introduced to from day one with dimension like wrap  content.  You could also truncate the text.  You've probably tried doing this by adding ellipses  if the text extends too far.  Or you can have some sort of combination  where you might display an abridged version of the text  showing like a summary, but then have some affordance that  takes the user to see the full length.  And the YouTube app demonstrates all of these techniques.  On the home screen, here we've got  each of the item widths which match the device width.  But the item height is unconstrained.  Because the list is vertically scrollable,  it means that the items can grow as large as needed.  And so if the video titles are long or novel-like,  it doesn't matter.  The view is going to extend as much as needed.  And the titles will just wrap.  But there's also cases where width and height constraints  are necessary, potentially because you're  trying to maximize the amount of content  that you're trying to fit on the screen.  In these cases, where you've got fixed size views,  it means that sometimes text needs to be ellipsoised.  You can't fit as much text as you want inside.  You can't extend the view.  So you need to indicate that it's  an intentional choice for you to ellipsoise or truncate the text.  But this isn't enough.  If this is the only place where you can read this text,  then it's important that, well, one,  we've lost sight of our original goal, which  was to make text readable.  So what can this ellipsoise mean?  It doesn't need to be bad?  No.  Ellipsoise can serve as a subtle call to action,  some sort of like a click here for the full story.  So when you click on the text, the ellipsoise text  in the video list, it takes you to the video detail, where  you can expand or you can see the video titles in full.  You can expand to see the descriptions as well.  The descriptions.  So I don't know how often people are surfing on YouTube,  but people like to fill out the descriptions a lot.  The platform is for video, but people like to write a lot.  In this example, the user needs to click on the title  to see expanded content.  But it's not only the descriptions  that are made visible.  The subscriber and the views format changes.  So things aren't abbreviated anymore.  You can see things in long form content.  But you still need to be careful.  Even in the cases where you've got more space,  remember to check for the cases where text might  be unintentionally cut off.  In this case, where we're ellipsoising the subscriber  count, the information here is important,  but not necessarily when you click through to the next page  of the video details page.  Here, maybe we could have done wrap content instead.  And if you're lucky enough to have 5 million subscribers,  then maybe it's OK for the subscribers  where to be on the next line.  And sometimes it's better to hide these elements entirely  rather than to show them partially obscured.  The good news is, if you can handle this sort of varying  text length already, the next step is easy.  The next step is about supporting different font scales.  So you should use scale-dependent pixels, so SPs,  where this unit is useful.  The user is able to change the font scale at a system level,  and our app should respect that.  Doing this correctly, for me, is the biggest impact  you can have in terms of supporting vision-impaired users.  Because it means, well, for me, this  is the easiest way your app can break.  So you increase the text size because you can't read something  from the normal reading distance,  and then suddenly all the layouts break.  You get ellipsoid text.  You get overlapping text.  Well, worst case scenario, you can't read stuff.  Best case scenario, it looks ugly.  And there's two parts of what this means for doing it  correctly.  First, use SPs instead of DPs so that the system can apply  that size transformation for you.  And secondly, make sure that as the text size increases,  text size is in cutoff.  So that whole last section I talked about.  The user is not able to pick what ever size they like.  In my testing, I found that there's four scaling factors,  at least on the Pixel phones, which range from 0.8 to 1.3.  Mitchell told me just before the talk that also the OEMs  can change these or provide different options.  So he's seeing it at 1.5.  So the testing doesn't need to be to the extremes.  You can test up to, for example, 1.5 or up to 2.  And it's enough.  To make that easier, the testing easier,  we wrote a JUnit rule to help.  So as part of your espresso tests,  you might be using activity test rules.  Activity test rules work in that when your espresso test  starts running, your activity spins up.  And then after your test finishes, it tears down.  So what can we do?  We can combine this.  You can combine multiple test rules with a rule chain.  And one of the rules that we created at Nevada  was the font scale rule.  So in this case, where the font scale rule wraps  the activity test rule, the font size on the device  will be changed to begin with.  Then your activity will spin up.  So it's already at the correct size.  Then your test will run.  The activity will tear down.  And then the font size will be reset to the original value.  This isn't so useful because it's kind of  hard to detect when your layouts break.  But if you combine it with other test rules,  like the screenshot test rule, I think Facebook has one,  for sure.  There's other ones available.  You can use it to speed up all the manual testing  that you have to do.  I'm going to skip past this next section about making  your text color considerate.  There's two main points to consider really.  It's don't convey information with color only.  Like provide some other affordance,  like making it bold or underlined.  And making sure that you test the color contrast ratio as well  to make sure that whatever text or iconography that you have,  it's distinct enough from the background to be readable.  So in this case, you've got that gray background  behind the play controls.  So no matter what the image is behind,  no matter what the video is, you can still see the controls.  And a structured guide to accessibility on Android  would be kind of incomplete without mentioning  accessibility services.  So an accessibility service, hands up, no one.  Call.  So maybe the one that you will be most familiar with  is TalkBack.  It's a software implementation of an assistive technology.  It acts as a screen reader.  So it's used by Vision and Pedge users.  So they can read what content is on the screen.  And it also acts as an interaction helper as well.  So the users can use gestures, like swiping and double tapping  to interact with the widgets on their phone.  So it still does these two things  that we mentioned at the beginning.  It conveys information to the user,  and it provides affordances for them to interact.  So TalkBack's the most familiar one.  With TalkBack, users can navigate through elements  on the screen sequentially.  Double tapping anywhere on the screen  will send a click event to whatever's focused.  When I was collecting feedback, someone  asked what makes a good content description.  A content description is a metadata  that's assigned to the view.  It is readable by any accessibility service.  And TalkBack will use it as the spoken description  for whatever view is focused.  So what makes a good content description?  A good content description describes what a view is  and nothing more.  So you don't necessarily need to say  that it's a button or an image.  You can describe it.  I think Samsung tried to push really hard for all the buttons  to be labeled as buttons, which is why you might see that  in some of the Samsung apps, or maybe further.  But now we've got usage hints.  So it's enough to say that what the view represents.  So here we've got YouTube and Search rather than YouTube  logo and magnifying glass.  But how do you describe these actions?  So in this case, we've got a view group.  Our view group here contains quite a bit of information.  And it's not just individual views that  need content descriptions.  If you set the description on a complex view group,  then it means that you're telling TalkBack  explicitly what you want it to say.  Otherwise, it's going to try and concatenate the description  from the elements inside, which might be too verbose.  So that's something that you need to talk to your product  owner about and your designers about.  How do you specify the action?  If you're just describing what the view is,  how do you say what happens when you interact with the view?  So you can use usage hints.  Use of hints are available from, I think, API 16,  but you can customize them from API 21.  These are, if a view is actionable, for example,  if it's clickable or long clickable,  TalkBack will read the description out loud,  and then it will pause for a second and then  follow by the hint.  So in this case, it says double tap to play the video.  By default, it will say double tap to activate or double tap  and hold to long press.  But these aren't helpful.  So you can customize them.  The way you do that is using accessibility delegates.  You can add additional metadata about the view  to the accessibility node info objects,  where here we're specifying that the click action is  associated with the play video label.  Or if you're using Android KTX, you  can use this extension function to set usage hints.  And that's pretty much it.  So if you're after a base level of support for TalkBack users,  content descriptions, and use the chance.  But we're not after a base level.  We're looking to raise the bar.  Since we saw that users navigate sequentially  with touch base gestures, can we improve that?  So imagine you've got a long list of items.  The user's going to need to swipe a lot to get  through each item.  Instead of having three clickable areas per item,  you can have one.  This means that you only need a single gesture to navigate.  But you can't just get rid of actions  and reduce the functionality, because that's not  making it accessible.  That's making it less accessible.  Instead, so when a user clicks on an item,  we can display all of the actions in a dialog  like a bottom sheet.  Doing this across the app, wherever  we're looking to simplify view groups,  will lead to a consistent user experience  for TalkBack users and also keyboard users or switch access  users.  You can, again, use the accessibility dialog  if you want to expose these to the power users  or for accessibility services.  Here, you just need to override another method,  unperform accessibility action, where  you call back to your listener.  To make it easier to implement this and the dialog stuff  without duplicating code, you can use accessibility tools  from the VodA.  Here, we can use a menu resource to inflate a menu  and then set that as your accessibility delegate.  Finally, you can also add actions to the UI where necessary.  So consider the video controls overlay,  which usually disappears after a few seconds.  If TalkBack is enabled, YouTube avoids the timed auto  dismiss so you can change behavior.  It adds an explicit dismiss button to the overlay  so it stays on the screen until the user explicitly  dismisses it.  In addition, because the seek bar controls are fiddly  to use with TalkBack, there's additional rewind and forward  buttons available.  So that was a really quick introduction  to accessibility on Android and what you can do today  to start influencing it in your app.  There's stuff about making your text readable,  making sure that your layout is responsive so that you're not  cutting off content unintentionally,  making sure that your text is scalable so that it respects  the user's preferences, making sure  that the colors are chosen considerably  so that you're supporting users that have difficulty  with low color contrast.  And then finally with TalkBack users as well,  making sure that you're improving the navigation  and providing good content descriptions.  If you have more questions around today and tomorrow,  otherwise, Nevada, our hiring.  Thank you.  [? Thank you.?]  Thank you, Attal.  We have five minutes for questions.  You have two microphones in the middle.  Or you can ping me directly outside anywhere.  Someone found my email somewhere, so they did that.  That's OK as well.  Cool, thank you.  Thank you.  Thank you.
_DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_0_2183.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_2184_2831.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_2832_4067.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_4068_6155.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_6156_7079.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_7080_8963.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_8964_10379.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_10380_10979.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_10980_12359.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_12360_13079.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_13080_14387.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_14388_14759.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_14760_15263.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_15264_15551.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_15552_16739.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_16740_19127.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_19128_20795.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_20796_20975.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_20976_21239.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_21240_21767.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_21768_22895.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_22896_22967.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_22968_23195.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_23196_24707.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_24708_25511.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_25512_26531.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_26532_26771.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_26772_27119.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_27120_27767.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_27768_28535.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_28536_29003.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_29004_29435.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_29436_29675.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_29676_30167.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_30168_31247.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_31248_32231.png _DCBerlin18_210_Munim_A_Structured_Guide_to_Access_dm05qny_kfE_32232_32241.png