Inclusive design
CC Attribution - ShareAlike 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 and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Brewin, Leonie
When we speak about accessibility in design, we refer to the degree in which a product or service is available to every user, regardless of language, culture, location or physical or mental abilities. Designing applications for such a diverse set of users can be a daunting task for any designer, so this talk will introduce a set of guidelines that can help us to integrate accessibility considerations into our everyday design process, without hindering creativity.
 Thank you. Oh, I've already gone too far ahead. Okay, cool. So I want to start off by speaking a little bit overall about user-centered design, and then I'll go into the more specifics of inclusive design, so designing for accessibility. So the most important thing that we need to do is understand and empathize with our users. So user-centered design is the practice of actively engaging with our users as we develop our products, and really learning to feel how they feel. So to understand the users themselves, understand their needs, and also understand what their current experience is. So not just their experience in terms of the applications that we're building, but their experience as a whole across their whole customer experience. And it's really important here for us to, for designers to understand, but also for the entire team to understand. So it's absolutely essential that designers, developers, POs, everyone is involved in this process of user-centered design, because the more connection we have with our users, the more empathy we will have, and the more ability we will have to be able to create products that work for them. So once we understand our users and we have a good understanding of their current experience, maybe areas where it falls down, the experience falls down, or areas where it's particularly successful, we'll be able to identify key opportunities. So we can work out opportunities to improve the experience for the user, and also allow the business to benefit from this, from this, from the advantage. So then we can move on to concepting and iterating. So we have a good idea of our users, we have a good idea of their needs. We've identified opportunities to improve the experience. So we can start concepting, prototyping, iterating on those prototypes, and testing with our users to ensure that we are validating what we're doing the entire time. So, and that allows us to release our applications with confidence to the place store. So in short, user-centered design, if we're able to identify the user needs effectively, then we'll be able to come up with solutions that bring value to the user. And if we can bring value to the user, the likelihood of having increased usage is higher and the business will, as a result, be more successful. So what's inclusive design? Inclusive design is the extent to which a product or service is available and usable by people with the widest range of capabilities. So it's making sure that we don't just concentrate on one group of users that actually we extend our product so it's available and usable by a much wider range of people. So I have Wayfinder, which is a really nice example of inclusive design. It's a product which was created by us too in London. And the main aim of this product was to make travelling on the London underground more inclusive to users with visual impairments. So they conducted various different methods of research. They spent time with groups of vision impaired users. And they conducted interviews and focus groups to try and get a really overall understanding of their experience as a whole, what it is that they go through day to day when they're trying to navigate on the London underground. So they also spent time observing these users. So as they're just spending time seeing exactly how they interact, what problems they come up against as they go through the transport system. And they also use simulation. So the team got a set of goggles that could essentially simulate different types of vision impairment. So the researchers themselves and the designers themselves were able to see exactly what the vision impaired users were going through. So it meant that their ability to feel how the users were feeling was much higher. So they were much more able to create a solution that worked well. So the main things they found out in their research was that travelling independently is a huge challenge for these users. They come up with a lot of troubles along the way. And they're really dependent on assistance. So they don't have the ability to be able to travel independently with confidence. So they come up with a solution, which is essentially an indoor navigation service, which uses Wi-Fi beacons to see exactly where the user is in the space and guide them effectively with voice directions through the underground. So this, I have a quote here from the Lander Underground. Ultimately, this innovative project is about giving our vision impaired customers the flexibility to travel with the same independence and spontaneity as everyone else. So this sums up inclusive design really well for me. I think it's essentially saying that when we're creating products or services, we need to make sure that we're including everyone and that we're not excluding people who are potentially less able for whatever reason. So what do we need to consider in Android? It's essentially this, trying to make products for our users that can be used by as many people as possible without necessarily having to create a completely separate experience. So dependent on the use case, some users will require vastly different experience, but in the majority of cases, we should be able to just make a few small tweaks along the way to improve the experience. So in this talk, we'll consider vision, non-touch users, language, cognition, and environment. So, and you'll be able to take away some, give an overview of the system accessibility front, the system accessibility services. Also, what we can do to enhance these services, to make them as usable as possible for the user, and also any additional considerations that we should be thinking about along the way, which for instance, when we can't necessarily rely on the system accessibility settings being turned on. And I'll also leave you with a design checklist. So just at the end, so you can go through when you're developing and designing to make sure that we're covering the various different opportunities. So throughout the presentation, I'll be using the times and the Sunday times as an example. And the times and the Sunday times are a newspaper based out of the UK. And they, their product allows users to read the news essentially, to watch videos from the Premier League, to play games, to save articles for offline usage to read later, and also to share the articles with friends and family. So I'm going to start with vision considerations. So this could be blind, partially sighted or color blind users, but could also be environmental factors, such as you're outside in the bright sunlight, or you have your screen brightness turned down. So color contrast is one of the main things that I'm considering when I'm designing the interface itself. There is a color contrast accessibility setting in an Android already built in. So you can see essentially what it does is turn your text either black or white. And if it's a lighter color, then it might add a darker background. So for the times and the Sunday times, we had two different considerations when we were designing the color contrast and ensuring that the color contrast was high enough. The first was this section color, the green on the tab bar. So each traditionally or historically in the times, each of the different sections in the newspaper, in the printed newspaper, have a different color. So it helps the user to know where they are in the newspaper as they're flicking through. And we wanted to be able to bring exactly the same thing across to the digital version. So we also found that through the user testing that with this section color changing color as the user swiped through each tab, it gave the user a much better understanding of where they were. And it also added to the brand of each of these sections. So the problem was that these section colors were with the white text on top, the contrast just wasn't high enough to meet the web accessibility standards. So we needed to work with the editorial designers to darken these colors slightly to ensure that the white text was actually legible to users with low vision. So that was the first thing. And the second was you can see there's a difference on these two screenshots. The one on the right is the one that we went with in the end. So when we started designing the tab bar, we went with the standard Android tab design. So we had 60% opacity on those non-selected states and 100% opacity on the selected state. But the problem that we had in order to make the contrast sufficiently high enough, we would have had to increase that level of opacity. Otherwise, we would have had to really darken the section colors, which would have just taken away from the brand and the experience of the application. So we also have text resizing. So it's just in the accessibility settings. You can turn on large text and essentially it just increases the size of the text across your device. So with the times and the Sunday times being a newspaper app, it's largely about reading content. So we wanted to give the user full control of what the text size is within the application. So directly from the article screen, they can tap on the text resize icon up at the top and change between three different sizes. So this actually works alongside the text resizing system accessibility settings. So if the system accessibility settings are turned on, then it would increase from whatever settings are set here. So we did a fair amount of usability testing around text sizes. The demographic for the times users is slightly older. So they're more likely to have deteriorating vision. And we found that generally about 16 SP is about right for the legibility. And we also played around with the line heights. To find line height didn't make a huge difference. But the color contrast and the size of the text was really important. So we also have color blindness. So one in 12 men are affected by color blindness and one in 200 women. So it's a reasonable amount of people to be considering. Again, in the Android accessibility settings, you can choose a color correction mode. This is a really nice example of not of considering color blind users. So ensuring that we never use color as the only indicator to communicate something. So we especially need to consider this when we're thinking about form validation and things like that. Make sure that we're not just using color to show that there is a problem with this particular form field, for instance, instead using icons and text to describe the problem. So talk back is one of the biggest Android accessibility settings. It essentially allows the user to navigate the screen without necessarily needing to be able to see the screen in full. So it reads as the user navigates through, it will read back exactly what the content that the user is on. So for the times, you can see we have this sequential navigation. So talk back users often will navigate through the talk back settings left, sorry, swipe right to next and swipe left to previous. They can also double tap to select something or move their finger around the screen and the screen reader will read whatever is underneath their finger. So you can see here we just have the user swiping through and swiping back. So we also, we need to consider our content descriptions and usage hints. So as the user is going through, we can specify exactly what it is that the user is hearing. So if it is an action, it's especially important. So instead of saying button, you should be able to say the action of that button and exactly what will happen if they select that button. Next, cool. You also might need to consider alternative user interfaces. So you can see here on the left-hand side, very similar to the screenshot I showed you earlier for the tab navigation. But on the right-hand side, we have a version for when talk back is enabled. So we had this, the trouble that it with the tab navigation and the sequential navigation that the user would have to go all the way through every single tab before they got down to the article. And the main point of this, if this application is to be able to read the article. So we just changed the navigation from a tab bar to a multiple selection. So the user is able to go all the way through to, all the way through from the section navigation to the article. And they can just double tap to open up a dialogue to see, to see the additional sections. It's also great to think about the focus and content groupings. So as I say, we have largely sequential navigation being used. So you may choose to group content and then give that a content description so that it doesn't necessarily read everything. And that basically means in this example, we've grouped the main headline and image area. So the user is able to quickly get down to the content. We also split the paragraph text into separate items. So the user could easily navigate through. So quite often these articles are really long. So it is important for them to be able to just navigate back and forth if they've read an article previously. And last of all, we have transient views. So we had a problem with our snack bar in terms of for talk back users especially, where if a, say, delete an item and the snack bar comes up, then normally an Android user would set your snack bar to stand for three or five seconds. And they're the only two options. And of course, if the user is at the top of a list, the chance of them getting down to the bottom of that list before then reaching the snack bar to be able to press undo, for instance, then it's going to, the likelihood of them getting there is really small. So we made the call instead to keep the snack bar persistent. So we weren't removing that functionality for talk back users. So you can see here we have the undo button and we also have a dismiss button on the right hand side. So I'll talk about non-touch users. So non-touch users is essentially anyone who is navigating through their device using an external device. So they may have mobility impairments, but they also may just be choosing and they may have just got a tablet and they use it choosing to use a keyboard or a D-pad or something like that to navigate. Now, so we have various, we need to be considering the view states for these users. It's also worth saying actually if we consider, if we manage to work out all of these view states and you have a user who's using your application on Android TV, for instance, you essentially have a quick win for a really like simple Android TV app. So the view states, I think we're probably considering most of them already in our day-to-day practice. We have the clickable views which would need a default focus and a pressed state. Then views that can be disabled where we just need to add an additional disabled state. Then we have non-clickable views. So that's for views which can't be clicked. So we need some way of indicating if they're a list item which can't be clicked in a list of other items that can be clicked. We need to just let the user know that that's not a clickable item. Then we have the selectable views as well. So we need to ensure that we have a selected state, for instance, the today's edition in the navigation drawer here. We also have language. So ideally we'll make sure that our applications cater for as many languages as possible. But of course we need to make sure that they're actually relevant to our use cases and relevant to the applications that we're building. So as I say, relevance. It's worth considering language in the design process because we need to make sure that for languages that potentially have longer words as opposed to shorter words, we need to make sure that our layouts are responsive enough so that they can respond to, oh. Thanks, Daseen. Sorry about this. Cool. Yeah. So we need to make sure that we have responsive layouts so that the text can wrap accordingly. It's also worth thinking about font support. So if you have one particular font and you've chosen to support various different languages, you need to make sure that that font can support the various different languages. Okay. And last up we have cognition. Now the considerations around cognition are essentially thinking about how much like cognitive load you're putting on the user, how much emphasis or reliance are you putting on the user putting effort into understanding the application that you've presented to them. So layout is extremely important when it comes to cognition. Just how much the user has to think about what they're doing. If you have a nice, clean, simple layout, it's going to be much easier to understand and the user is much more likely to continue using the application. If they feel overwhelmed or like there's just too much going on the screen, then it's going to be much harder for them to comprehend and it's going to be much harder. It'll be much less likely to continue using the product. We also have copy. So we need to make sure that any of the copy that we use is as concise as possible. Especially this is useful when especially when we're thinking about the content descriptions in talk back. But generally any user who is using your application, the more concise and descriptive your text is, the more likely they are to understand it and the more likely they are to be able to move forward. This is especially important when it comes to actions. So buttons or links, anything that requires the user interact to interact directly. Okay. And error guidance. So I think we need to be more supportive when it comes to error guidance so we can do as much as we can to avoid the user making mistakes at the same time as helping them if there is a mistake. So especially again, inform validation or something, we can give certain guidance on exactly what it is they need to input and then if anything isn't valid, then we can help them and direct them to a way that they'll be able to get past. So it's also worth thinking about time. So similarly to the snack bar, we need to ensure that we are giving the user enough time to comprehend exactly what's happening on the screen. This is especially important when it comes to motion. So motion can be something which is incredibly useful for guiding the user through an experience and from taking them from one state to another, from guiding their attention from one object to another. But if we go too crazy with motion, if there's things flying all over the place, it's just going to overwhelm them and they're not going to be able to feel comfortable using the application. So we also have environmental factors to consider. So first of all, as I mentioned earlier, if you're in a bright space and you can't see your phone so well, then things like color contrast will really help. And also connectivity, so the very nature of mobile devices is that you'll be moving around a lot. The users will have better connection sometimes and not so good connection the rest of the time. So in the times we implemented something, so essentially with the times they have new additions three, four times a day. So we will actually download the addition in advance so that we're not necessarily reliant on data connection when the user comes to use the application. So the main use case of the times on mobile is for a user might get up in the morning. They're most likely to be using their mobile when they're on the train on the way to work. So it's really important for us at that point to be able to ensure that they have all of the articles that they want to be able to read. So we can download the package in the morning when they're on Wi-Fi and then they have all the content ready even if they don't have data at the time. So we also have potentially you could consider alternative input methods. So if a user is wandering down the street, they only have one hand free. Is there another way they could interact with the device? For instance, the voice input on WhatsApp is super useful for just wandering down the street if you don't have time. You don't necessarily want your users to be concentrating on the device if they need to be aware of what they're doing around them. So we have our design checklist. We need to consider color contrast and text size, focus sequence grouping, content descriptions and potentially alternative UIs for talk back users if we want to avoid that constant scrolling through information. And we have our view states for D-pad or keyboard users. And we can consider language for whichever languages you might be relevant for. And also offline usage as I just mentioned. And then just for the cognition side, we need to ensure that our layouts are as clear and concise as possible. So we're not relying on the user's input too much. And also ensure that we're giving supportive error guidance. So a quote from the World Health Organization. Overcoming the difficulties faced by people with disabilities requires interventions to remove environmental and social barriers. So this is our opportunity to be able to remove these barriers in our applications and make our applications more accessible to the wider world. So as far as actually getting this done in your organizations, I found the most important thing is having a shared understanding of what the company's commitments are to designing inclusive design. So exactly what the commitments are in the company and also what the benefits are to the company. That by designing more inclusive design you will be opening up your much wider customer base. I would also suggest trying the accessibility services for yourself. Just try and use your own applications with the different accessibility settings turned on. Just experience it for yourself and it will hopefully give a better understanding of your user's experiences. And also make it part of the everyday process. I think these considerations are really hard to implement if you kind of get to the end of a project and then you decide, okay, let's do accessibility now. So it's really important for us to make it part of the design process and part of the development process. So it's in the acceptance criteria for the developers and it's also in the design tickets for the designers. So we actually have a design checklist that we've just started implementing to make sure that we're considering all of the different accessibility states before a designer is considered complete. So I have a few references for you. Of course we have the Google material accessibility guidelines. I would have a read. Like actually you can get through it pretty quickly. It's really concise. It's really, really useful. And of course I've been talking mainly from a design perspective but as far as an implementation perspective goes, Kelly Schuster and Atul Minam are like both GDE specialists in accessibility. So if you have any questions, send them their way. Also, so we've done some work with the Royal National Institute for the Blind in the UK and also worked with the digital accessibility centre. So I don't know any in Germany as of yet. But these guys are absolutely specialists in their fields. They can help with arranging usability testings with their group of users. They can do audits to just let you know how well you're doing in your applications as far as accessibility is concerned. And they're really supportive. So any information again, they're a really good source. Thank you. Thank you, Leonie. Your questions, Leonie. Yes. Hello. Thank you for the talk. My question is how do you deal with supporting different font sizes? Because supporting different languages is a challenge itself. But do you make different layouts and how deep of an understanding of how layouts are built in Android should a designer have? Say the last bit again. I mean, the designer should know some technical issues in the Android system. How deeply should the design delve into the technical aspects? I think it's super important that the designers generally have a really good understanding of how the layouts work and also how they're built. So we try and work closely with our developers to make sure that we have an understanding of how it's built and also with responsive layouts. So we'll design for each of the different Android buckets of different sizes so we can make sure that the layouts respond in different devices. Any more questions? Maybe I have one. I don't want to be impolite, but looking here, you see, the room is not packed. It's not exactly packed. There were other talks when it was packed. Do you think the topic of design and the topic of creating software for somehow impaired people is not yet popular enough and what can one do to change this? I think often, maybe the title of my talk, I think often accessibility is associated only with disabled or impaired people. And actually accessibility is about the wider world, including absolutely everyone as much as you possibly can. So I think maybe designing for accessibility has some form of negative connotation. But really, it would be great if we can start talking about it as more of an inclusive design process so we can really push it in the work that we're doing. I have a very particular and maybe niche question. I'm not sure. Some Android devices and mods as well have adaptive screens now, which adjust contrast and things like that adaptively and dynamically. How at all do you cope with that in app design? I think if we work to the contrast guidelines, then in theory, it shouldn't make a difference. Because like similarly to the Android system settings, it will make a change if there's a need for a change. Whereas if our layouts and our designs don't need a change, then in theory, it shouldn't affect it. But let's chat after. Does that answer your question? Okay. Any more questions? Yeah. Hi. I come from India, actually. Space is very niche for developers to get into accessibility and enforce it. One reason why the room probably is not full is what I think is there's no legal ambit forcing developers to make sure accessibility is there. Like that's section 508 where India produces software for the US market and the UK market, but you get away by doing absolutely nothing for the accessibility spectrum. Do you think getting into like a W3 school, including legal ambits, making sure accessibility guidelines are followed by developers will ensure probably one, the room is full? Or secondly, making sure that all the software don't have to go through what you said, change of design later on because there's a case that's come up to you? Yeah. I think it's probably tricky to just like implement a law and expect everyone to do it because the reality is maybe people wouldn't do it. But I think that what we really need to do is just start talking about it more as a community so that we understand what designing for accessibility is and exactly what we need to do to work it out. Like, I mean, in my ideal world, like everyone designs perfectly accessible apps. I think maybe we need at least as a first step, just more awareness of the things that need to be done. And then once there's awareness, maybe you can start implementing rules. Okay. Thank you.
 Thank you. Oh, I've already gone too far ahead. Okay, cool. So I want to start off by speaking  a little bit overall about user-centered design, and then I'll go into the more specifics of  inclusive design, so designing for accessibility. So the most important thing that we need to  do is understand and empathize with our users. So user-centered design is the practice of  actively engaging with our users as we develop our products, and really learning to feel  how they feel. So to understand the users themselves, understand their needs, and also  understand what their current experience is. So not just their experience in terms of the  applications that we're building, but their experience as a whole across their whole customer  experience. And it's really important here for us to, for designers to understand, but  also for the entire team to understand. So it's absolutely essential that designers,  developers, POs, everyone is involved in this process of user-centered design, because the  more connection we have with our users, the more empathy we will have, and the more ability  we will have to be able to create products that work for them. So once we understand  our users and we have a good understanding of their current experience, maybe areas where  it falls down, the experience falls down, or areas where it's particularly successful,  we'll be able to identify key opportunities. So we can work out opportunities to improve  the experience for the user, and also allow the business to benefit from this, from this,  from the advantage. So then we can move on to concepting and iterating. So we have a  good idea of our users, we have a good idea of their needs. We've identified opportunities  to improve the experience. So we can start concepting, prototyping, iterating on those  prototypes, and testing with our users to ensure that we are validating what we're doing  the entire time. So, and that allows us to release our applications with confidence to  the place store. So in short, user-centered design, if we're able to identify the user  needs effectively, then we'll be able to come up with solutions that bring value to the  user. And if we can bring value to the user, the likelihood of having increased usage is  higher and the business will, as a result, be more successful. So what's inclusive design?  Inclusive design is the extent to which a product or service is available and usable  by people with the widest range of capabilities. So it's making sure that we don't just concentrate  on one group of users that actually we extend our product so it's available and usable by  a much wider range of people. So I have Wayfinder, which is a really nice example of inclusive  design. It's a product which was created by us too in London. And the main aim of this  product was to make travelling on the London underground more inclusive to users with visual  impairments. So they conducted various different methods of research. They spent time with  groups of vision impaired users. And they conducted interviews and focus groups to try  and get a really overall understanding of their experience as a whole, what it is that  they go through day to day when they're trying to navigate on the London underground. So  they also spent time observing these users. So as they're just spending time seeing exactly  how they interact, what problems they come up against as they go through the transport  system. And they also use simulation. So the team got a set of goggles that could essentially  simulate different types of vision impairment. So the researchers themselves and the designers  themselves were able to see exactly what the vision impaired users were going through.  So it meant that their ability to feel how the users were feeling was much higher. So  they were much more able to create a solution that worked well. So the main things they  found out in their research was that travelling independently is a huge challenge for these  users. They come up with a lot of troubles along the way. And they're really dependent  on assistance. So they don't have the ability to be able to travel independently with confidence.  So they come up with a solution, which is essentially an indoor navigation service,  which uses Wi-Fi beacons to see exactly where the user is in the space and guide them effectively  with voice directions through the underground. So this, I have a quote here from the Lander  Underground. Ultimately, this innovative project is about giving our vision impaired  customers the flexibility to travel with the same independence and spontaneity as everyone  else. So this sums up inclusive design really well for me. I think it's essentially saying  that when we're creating products or services, we need to make sure that we're including  everyone and that we're not excluding people who are potentially less able for whatever  reason. So what do we need to consider in Android? It's essentially this, trying to  make products for our users that can be used by as many people as possible without necessarily  having to create a completely separate experience. So dependent on the use case, some users will  require vastly different experience, but in the majority of cases, we should be able to  just make a few small tweaks along the way to improve the experience. So in this talk,  we'll consider vision, non-touch users, language, cognition, and environment. So, and you'll  be able to take away some, give an overview of the system accessibility front, the system  accessibility services. Also, what we can do to enhance these services, to make them  as usable as possible for the user, and also any additional considerations that we should  be thinking about along the way, which for instance, when we can't necessarily rely on  the system accessibility settings being turned on. And I'll also leave you with a design  checklist. So just at the end, so you can go through when you're developing and designing  to make sure that we're covering the various different opportunities. So throughout the  presentation, I'll be using the times and the Sunday times as an example. And the times  and the Sunday times are a newspaper based out of the UK. And they, their product allows  users to read the news essentially, to watch videos from the Premier League, to play games,  to save articles for offline usage to read later, and also to share the articles with  friends and family. So I'm going to start with vision considerations. So this could  be blind, partially sighted or color blind users, but could also be environmental factors,  such as you're outside in the bright sunlight, or you have your screen brightness turned  down. So color contrast is one of the main things that I'm considering when I'm designing  the interface itself. There is a color contrast accessibility setting in an Android already  built in. So you can see essentially what it does is turn your text either black or  white. And if it's a lighter color, then it might add a darker background. So for the  times and the Sunday times, we had two different considerations when we were designing the  color contrast and ensuring that the color contrast was high enough. The first was this  section color, the green on the tab bar. So each traditionally or historically in the  times, each of the different sections in the newspaper, in the printed newspaper, have  a different color. So it helps the user to know where they are in the newspaper as they're  flicking through. And we wanted to be able to bring exactly the same thing across to  the digital version. So we also found that through the user testing that with this section  color changing color as the user swiped through each tab, it gave the user a much better understanding  of where they were. And it also added to the brand of each of these sections. So the problem  was that these section colors were with the white text on top, the contrast just wasn't  high enough to meet the web accessibility standards. So we needed to work with the editorial  designers to darken these colors slightly to ensure that the white text was actually  legible to users with low vision. So that was the first thing. And the second was you  can see there's a difference on these two screenshots. The one on the right is the one  that we went with in the end. So when we started designing the tab bar, we went with the standard  Android tab design. So we had 60% opacity on those non-selected states and 100% opacity  on the selected state. But the problem that we had in order to make the contrast sufficiently  high enough, we would have had to increase that level of opacity. Otherwise, we would  have had to really darken the section colors, which would have just taken away from the  brand and the experience of the application. So we also have text resizing. So it's just  in the accessibility settings. You can turn on large text and essentially it just increases  the size of the text across your device. So with the times and the Sunday times being  a newspaper app, it's largely about reading content. So we wanted to give the user full  control of what the text size is within the application. So directly from the article  screen, they can tap on the text resize icon up at the top and change between three different  sizes. So this actually works alongside the text resizing system accessibility settings.  So if the system accessibility settings are turned on, then it would increase from whatever  settings are set here. So we did a fair amount of usability testing around text sizes. The  demographic for the times users is slightly older. So they're more likely to have deteriorating  vision. And we found that generally about 16 SP is about right for the legibility. And  we also played around with the line heights. To find line height didn't make a huge difference.  But the color contrast and the size of the text was really important. So we also have  color blindness. So one in 12 men are affected by color blindness and one in 200 women. So  it's a reasonable amount of people to be considering. Again, in the Android accessibility  settings, you can choose a color correction mode. This is a really nice example of not  of considering color blind users. So ensuring that we never use color as the only indicator  to communicate something. So we especially need to consider this when we're thinking  about form validation and things like that. Make sure that we're not just using color  to show that there is a problem with this particular form field, for instance, instead  using icons and text to describe the problem. So talk back is one of the biggest Android  accessibility settings. It essentially allows the user to navigate the screen without necessarily  needing to be able to see the screen in full. So it reads as the user navigates through,  it will read back exactly what the content that the user is on. So for the times, you  can see we have this sequential navigation. So talk back users often will navigate through  the talk back settings left, sorry, swipe right to next and swipe left to previous. They  can also double tap to select something or move their finger around the screen and the  screen reader will read whatever is underneath their finger. So you can see here we just  have the user swiping through and swiping back. So we also, we need to consider our  content descriptions and usage hints. So as the user is going through, we can specify  exactly what it is that the user is hearing. So if it is an action, it's especially important.  So instead of saying button, you should be able to say the action of that button and  exactly what will happen if they select that button. Next, cool. You also might need to  consider alternative user interfaces. So you can see here on the left-hand side, very similar  to the screenshot I showed you earlier for the tab navigation. But on the right-hand  side, we have a version for when talk back is enabled. So we had this, the trouble that  it with the tab navigation and the sequential navigation that the user would have to go  all the way through every single tab before they got down to the article. And the main  point of this, if this application is to be able to read the article. So we just changed  the navigation from a tab bar to a multiple selection. So the user is able to go all the  way through to, all the way through from the section navigation to the article. And they  can just double tap to open up a dialogue to see, to see the additional sections.  It's also great to think about the focus and content groupings. So as I say, we have largely  sequential navigation being used. So you may choose to group content and then give that  a content description so that it doesn't necessarily read everything. And that basically means  in this example, we've grouped the main headline and image area. So the user is able to quickly  get down to the content. We also split the paragraph text into separate items. So the  user could easily navigate through. So quite often these articles are really long. So it  is important for them to be able to just navigate back and forth if they've read an article  previously. And last of all, we have transient views. So we had a problem with our snack  bar in terms of for talk back users especially, where if a, say, delete an item and the snack  bar comes up, then normally an Android user would set your snack bar to stand for three  or five seconds. And they're the only two options. And of course, if the user is at  the top of a list, the chance of them getting down to the bottom of that list before then  reaching the snack bar to be able to press undo, for instance, then it's going to, the  likelihood of them getting there is really small. So we made the call instead to keep  the snack bar persistent. So we weren't removing that functionality for talk back users. So  you can see here we have the undo button and we also have a dismiss button on the right  hand side. So I'll talk about non-touch users. So non-touch users is essentially anyone who  is navigating through their device using an external device. So they may have mobility  impairments, but they also may just be choosing and they may have just got a tablet and they  use it choosing to use a keyboard or a D-pad or something like that to navigate.  Now, so we have various, we need to be considering the view states for these users. It's also  worth saying actually if we consider, if we manage to work out all of these view states  and you have a user who's using your application on Android TV, for instance, you essentially  have a quick win for a really like simple Android TV app. So the view states, I think  we're probably considering most of them already in our day-to-day practice. We have the clickable  views which would need a default focus and a pressed state. Then views that can be disabled  where we just need to add an additional disabled state. Then we have non-clickable views. So  that's for views which can't be clicked. So we need some way of indicating if they're  a list item which can't be clicked in a list of other items that can be clicked. We need  to just let the user know that that's not a clickable item. Then we have the selectable  views as well. So we need to ensure that we have a selected state, for instance, the today's  edition in the navigation drawer here. We also have language. So ideally we'll make sure  that our applications cater for as many languages as possible. But of course we need to make  sure that they're actually relevant to our use cases and relevant to the applications  that we're building. So as I say, relevance. It's worth considering language in the design  process because we need to make sure that for languages that potentially have longer  words as opposed to shorter words, we need to make sure that our layouts are responsive  enough so that they can respond to, oh. Thanks, Daseen. Sorry about this. Cool. Yeah. So we  need to make sure that we have responsive layouts so that the text can wrap accordingly.  It's also worth thinking about font support. So if you have one particular font and you've  chosen to support various different languages, you need to make sure that that font can support  the various different languages. Okay. And last up we have cognition. Now the considerations  around cognition are essentially thinking about how much like cognitive load you're  putting on the user, how much emphasis or reliance are you putting on the user putting  effort into understanding the application that you've presented to them. So layout is  extremely important when it comes to cognition. Just how much the user has to think about  what they're doing. If you have a nice, clean, simple layout, it's going to be much easier  to understand and the user is much more likely to continue using the application. If they  feel overwhelmed or like there's just too much going on the screen, then it's going  to be much harder for them to comprehend and it's going to be much harder. It'll be much  less likely to continue using the product. We also have copy. So we need to make sure  that any of the copy that we use is as concise as possible. Especially this is useful when  especially when we're thinking about the content descriptions in talk back. But generally  any user who is using your application, the more concise and descriptive your text is,  the more likely they are to understand it and the more likely they are to be able to  move forward. This is especially important when it comes to actions. So buttons or links,  anything that requires the user interact to interact directly. Okay. And error guidance.  So I think we need to be more supportive when it comes to error guidance so we can do as  much as we can to avoid the user making mistakes at the same time as helping them if there  is a mistake. So especially again, inform validation or something, we can give certain  guidance on exactly what it is they need to input and then if anything isn't valid, then  we can help them and direct them to a way that they'll be able to get past. So it's  also worth thinking about time. So similarly to the snack bar, we need to ensure that we  are giving the user enough time to comprehend exactly what's happening on the screen. This  is especially important when it comes to motion. So motion can be something which is incredibly  useful for guiding the user through an experience and from taking them from one state to another,  from guiding their attention from one object to another. But if we go too crazy with motion,  if there's things flying all over the place, it's just going to overwhelm them and they're  not going to be able to feel comfortable using the application. So we also have environmental  factors to consider. So first of all, as I mentioned earlier, if you're in a bright space  and you can't see your phone so well, then things like color contrast will really help.  And also connectivity, so the very nature of mobile devices is that you'll be moving  around a lot. The users will have better connection sometimes and not so good connection  the rest of the time. So in the times we implemented something, so essentially with  the times they have new additions three, four times a day. So we will actually download  the addition in advance so that we're not necessarily reliant on data connection when  the user comes to use the application. So the main use case of the times on mobile is  for a user might get up in the morning. They're most likely to be using their mobile when  they're on the train on the way to work. So it's really important for us at that point  to be able to ensure that they have all of the articles that they want to be able to  read. So we can download the package in the morning when they're on Wi-Fi and then they  have all the content ready even if they don't have data at the time. So we also have potentially  you could consider alternative input methods. So if a user is wandering down the street,  they only have one hand free. Is there another way they could interact with the device? For  instance, the voice input on WhatsApp is super useful for just wandering down the street  if you don't have time. You don't necessarily want your users to be concentrating on the  device if they need to be aware of what they're doing around them. So we have our design checklist.  We need to consider color contrast and text size, focus sequence grouping, content descriptions  and potentially alternative UIs for talk back users if we want to avoid that constant scrolling  through information. And we have our view states for D-pad or keyboard users. And we  can consider language for whichever languages you might be relevant for. And also offline  usage as I just mentioned. And then just for the cognition side, we need to ensure that  our layouts are as clear and concise as possible. So we're not relying on the user's input  too much. And also ensure that we're giving supportive error guidance. So a quote from  the World Health Organization. Overcoming the difficulties faced by people with disabilities  requires interventions to remove environmental and social barriers. So this is our opportunity  to be able to remove these barriers in our applications and make our applications more  accessible to the wider world. So as far as actually getting this done in your organizations,  I found the most important thing is having a shared understanding of what the company's  commitments are to designing inclusive design. So exactly what the commitments are in the  company and also what the benefits are to the company. That by designing more inclusive  design you will be opening up your much wider customer base. I would also suggest trying  the accessibility services for yourself. Just try and use your own applications with the  different accessibility settings turned on. Just experience it for yourself and it will  hopefully give a better understanding of your user's experiences. And also make it part  of the everyday process. I think these considerations are really hard to implement if you kind of  get to the end of a project and then you decide, okay, let's do accessibility now. So it's  really important for us to make it part of the design process and part of the development  process. So it's in the acceptance criteria for the developers and it's also in the design  tickets for the designers. So we actually have a design checklist that we've just started  implementing to make sure that we're considering all of the different accessibility states  before a designer is considered complete. So I have a few references for you. Of course  we have the Google material accessibility guidelines. I would have a read. Like actually  you can get through it pretty quickly. It's really concise. It's really, really useful.  And of course I've been talking mainly from a design perspective but as far as an implementation  perspective goes, Kelly Schuster and Atul Minam are like both GDE specialists in accessibility.  So if you have any questions, send them their way. Also, so we've done some work with the  Royal National Institute for the Blind in the UK and also worked with the digital accessibility  centre. So I don't know any in Germany as of yet. But these guys are absolutely specialists  in their fields. They can help with arranging usability testings with their group of users.  They can do audits to just let you know how well you're doing in your applications as  far as accessibility is concerned. And they're really supportive. So any information again,  they're a really good source. Thank you. Thank you, Leonie. Your questions, Leonie.  Yes. Hello. Thank you for the talk. My question is how do you deal with supporting different  font sizes? Because supporting different languages is a challenge itself. But do you make different  layouts and how deep of an understanding of how layouts are built in Android should a  designer have? Say the last bit again. I mean, the designer should know some technical issues  in the Android system. How deeply should the design delve into the technical aspects?  I think it's super important that the designers generally have a really good understanding  of how the layouts work and also how they're built. So we try and work closely with our  developers to make sure that we have an understanding of how it's built and also with responsive  layouts. So we'll design for each of the different Android buckets of different sizes so we can  make sure that the layouts respond in different devices. Any more questions?  Maybe I have one. I don't want to be impolite, but looking here, you see, the room is not  packed. It's not exactly packed. There were other talks when it was packed. Do you think  the topic of design and the topic of creating software for somehow impaired people is not  yet popular enough and what can one do to change this?  I think often, maybe the title of my talk, I think often accessibility is associated  only with disabled or impaired people. And actually accessibility is about the wider  world, including absolutely everyone as much as you possibly can. So I think maybe designing  for accessibility has some form of negative connotation. But really, it would be great  if we can start talking about it as more of an inclusive design process so we can really  push it in the work that we're doing.  I have a very particular and maybe niche question. I'm not sure. Some Android devices  and mods as well have adaptive screens now, which adjust contrast and things like that  adaptively and dynamically. How at all do you cope with that in app design?  I think if we work to the contrast guidelines, then in theory, it shouldn't make a difference.  Because like similarly to the Android system settings, it will make a change if there's  a need for a change. Whereas if our layouts and our designs don't need a change, then  in theory, it shouldn't affect it. But let's chat after.  Does that answer your question? Okay. Any more questions?  Yeah.  Hi. I come from India, actually. Space is very niche for developers to get into accessibility  and enforce it. One reason why the room probably is not full is what I think is there's no  legal ambit forcing developers to make sure accessibility is there.  Like that's section 508 where India produces software for the US market and the UK market,  but you get away by doing absolutely nothing for the accessibility spectrum. Do you think  getting into like a W3 school, including legal ambits, making sure accessibility guidelines  are followed by developers will ensure probably one, the room is full? Or secondly, making  sure that all the software don't have to go through what you said, change of design later  on because there's a case that's come up to you?  Yeah. I think it's probably tricky to just like implement a law and expect everyone to  do it because the reality is maybe people wouldn't do it. But I think that what we really need  to do is just start talking about it more as a community so that we understand what  designing for accessibility is and exactly what we need to do to work it out. Like, I  mean, in my ideal world, like everyone designs perfectly accessible apps. I think maybe we  need at least as a first step, just more awareness of the things that need to be done. And then  once there's awareness, maybe you can start implementing rules.  Okay.  Thank you.
_droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_0_491.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_492_599.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_600_755.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_756_803.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_804_947.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_948_995.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_996_4043.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_4044_9035.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_9036_16007.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_16008_16055.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_16056_17603.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_17604_17819.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_17820_17867.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_17868_18263.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_18264_27683.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_27684_27767.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_27768_27827.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_27828_29567.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_29568_29675.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_29676_35747.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_35748_35903.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_35904_42431.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_42432_42755.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_42756_42803.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_42804_43031.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43032_43163.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43164_43211.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43212_43511.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43512_43775.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43776_43907.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_43908_44207.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_44208_44279.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_44280_44363.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_44364_44495.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_44496_45743.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_45744_45947.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_45948_46163.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_46164_48155.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_48156_48203.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_48204_48311.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_48312_48431.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_48432_48491.png _droidconDE__Leonie_Brewin___Designing_for_Accessi_NemAF2tJPxg_48492_48614.png