An accessible process for inclusive design (Google I/O '18)

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
[MUSIC PLAYING] JEN DEVINS: Hi, everybody. Thanks for coming. We're really excited to have you all here today. My name is Jen Devins. I lead the user experience team for Google accessibility. And with me, I have Andrea Wong-- she's a researcher on accessibility; Catherine Idylle, who is a designer on accessibility; and Bethany Fong, who is the lead designer on Google material design. We're really happy to have such a great crowd here that's interested in inclusive design and accessibility, and we're looking forward to sharing with you how you can make your products more inclusive. But before we dive in and get into specifics, we wanted to start with just some basics-- what is accessibility, inclusive design, and why it's important. As described by the Web Accessibility Initiative, accessibility, usability, and inclusive design are all very closely related. Their goals, approaches, and guidelines overlap significantly. And when we sit down to design and develop our apps, it's really effective to address them together. Let's start with accessibility. Accessibility focuses on enabling users with disabilities to perceive, interact, understand, and navigate tools and services and products, and that they can contribute equally without barriers. Now, some of the guidelines we think about with accessibility, such as clear color contrast or clear, concise writing, are useful not only to users with disabilities but also those that might be-- or that don't have disabilities but might be in different situations. For example, we know that alternative text can be useful to users who are blind and can't see the screen, as it describes the imagery and visual icons. Alternative text can also be useful to users who might be out in remote locations with low bandwidth or using old technology. Another example-- it's clear that providing enough time for users to interact with and read content on the screen is useful for users who might have a motor impairment or cognitive impairment. This extra time is also very useful for users that might be learning a new language or have low literacy, or children learning to read, or simply just people distracted. And this is how accessibility is a key component of inclusive design. Inclusive design is all about considering the wide range of human abilities. We think of age, gender, ethnicity, and others. And as you can see, accessibility overlaps significantly with these areas as well. And that's why we feel like accessibility is a really clear starting point. So at this point, we could just throw up on the screen a checklist of guidelines for you to follow to ensure that your product is accessible. And that's a great place to start, no doubt about it. However, what we've seen is that may often lead to a product that's technically accessible but not necessarily usable, let alone a great experience for all users. And this is where usability comes into play. Now how many people, by a quick show of hands, take time to reach out and get feedback and input from users? Quick show of hands-- right. It's an important and really useful thing to do, right? Unfortunately, we know that a lot of users with disabilities are left out of this really key critical point in the process. If we're not out there talking and observing our users, we'll never understand, what are their true experiences? What are their challenges? And most importantly, what are their insights that could actually benefit everyone? And in the end, you could be left missing out on a large number of potential users and also miss out on helping existing users who might be in these limiting situations. OK, so that's the basics. We've got the stage set. Now, we want to walk you through more of a case study to demonstrate how to design and develop with accessibility in mind. Today, we're going to use our fictional app. It's a travel and hospitality app called Crane. And we're going to use this throughout the rest of the talk to demonstrate specifics of how to make products more inclusive using the standard user-centered design methodologies, as well as material design system, which includes clear guidelines, components, and tooling. So to get this started, we're going to break it down into four primary stages. We have defining the product vision, design, development, and after design. Now, this framework probably seems familiar to you, and that's on purpose. We're not here to introduce yet another process for you to follow. Instead, we see this as a tool kit of ideas and things that you can do to enhance your product to make it more inclusive, because in the end, inclusive design is really just simply good design. OK, so now Andrea is going to walk through the first stage of defining the product vision. ANDREA WONG: Thanks, Jen. Stage one, defining the product vision. No matter what you're building, understanding what problems you're solving for users is the key to product success. So who are your users? Most teams start with the assumption that all their users are fully-abled, but that may not always be the case. So let's say you're building a photos app. And you think, well, why would someone who is blind use my photos app? Actually, a person who is blind may use your app because they want to take photos and then share them with friends and families or post them on social media, just like everyone else. Consider these three people on the screen. There's a man in a wheelchair with Lou Gehrig's disease. So he has impaired motor functioning for upper and lower body. There's a boy with a broken arm. And there's a woman holding a full bag of groceries. Let's have a pop quiz. Which of these three people have limited mobility. Raise their hand if you think it's the man in the wheelchair. OK, hands down. Raise your hand if you think it's the boy. Thank you. And lastly, raise your hand if you think it's the woman. So if you raised your hands all three times, you're correct. All three of them have a different relationship with limited mobility, whether it's permanent, like the man; temporary, like the boy; or situational, like the woman with the groceries. Yet, they're all experiencing the exact same need right now. It's a good reminder that for every single one of us, we'll have accessibility needs at some point throughout our lifetime. Disability is a much broader term than we might think. And often, when something doesn't work well for a user with no disabilities, that pain point is amplified for people with disabilities. And that's actually good news for you, because it gives you much clearer signals of what you should be focusing on. Because when everything doesn't work-- when something doesn't work for everyone, it clearly is something that you should be paying attention to. And that's, in fact, what we found with our studies at Google. All users have the same core needs because they're all trying to meet the same goal, whether it's sending a photograph, writing a email, buying CryptoKitties, whatever it is. So at this point, you're probably asking, well, how do I do research with people with disabilities? The answer is do what you usually do. Are you, let's say in the early stage right now, where you're just chatting and sitting down and talking to users? If you are, that's actually the easiest and the best time to be including users with disabilities into your process, because you can get their context, their needs, and everything right from the very start. You can ask the exact same questions as you would to someone without disabilities. The only difference is you have to ask a few additional questions about this assistive technologies they may be using and their context of use. So for example, you'll be asking, say, how do you use your assistive technologies when you're navigating a mobile device? Or how does your impairment impact or not impact your interactions when you're planning travel? Or maybe even, which workarounds, if any, do you use to get to what you need? And always, always follow up after each question with, why, tell me more, to really dig in there to get to the context of their needs. The bonus here is their answers may inspire new ways of interactions they've never thought of before. Or maybe you're past that stage already. That's fine. Right now, you're testing a low-fidelity paper prototype. That's fine. You can still test with people with disabilities. Let's say you're testing with a user who is blind and uses a screen reader, which is an assistive at the technology that reads out loud the contents on the screen. So you're doing that, but you don't have a screen reader-friendly prototype. What you can do here, though, is write a script of what the screen reader might verbalize and have someone on your team act as a screen reader. And that person can read each step out loud to the user as they walk through the user flow during the study session. By integrating people with disabilities, whenever you're talking to people without disabilities, you're automatically ensuring that their viewpoints will be included and part of the process throughout the entire design and the development phases. Along with understanding user needs, you need to have a general comprehension of assistive technologies and the different tools that people may use interact with your product. Trying the technologies yourself is a great place to start, but the best way to learn is to observe the real experts. Those are the people who use these technologies day in and day out. And if you can't find someone to observe in real life, that's OK. You can just go online and ask-- look for any kind of video. Whether it's like going to the ATM, going to the grocery store, there are countless great videos online to explain the different ways people use different technologies. The goal here is to understand what makes a good versus a poor experience, what are the common pitfalls, and the standard expectations that people have when using your site or app. Later, using our fictional app, Crane, we'll walk you through designing a great keyboard navigation model. Starting with a keyboard navigation model creates a very good foundation for you when building for other assistive technologies, which we won't go into here. You may be feeling a bit overwhelmed right now at how to design to meet all those needs, but the great thing about design inclusively is that people on teams have been working for years to understand what design inclusively actually means. So as Jen mentioned, material design components includes accessibility guidelines baked right in that anyone can follow, regardless of the size of your team. Doing the right thing, though, isn't necessarily mutually exclusive to good business sense either. It could even increase your market share. According to the American Institute of Research, who came out with this report a few months ago, working-age people with disabilities in the US alone have a discretionary income of $21 billion. That's the third largest market segment in the entire country. Then, if you think about their families and friends who may also use your product to interact with them, or they may just simply appreciate good design. And this is not just the US alone. According to Gartner, people with disabilities and their friends and family worldwide have a collective disposable income of $8 trillion dollars. Think about that. OK, that was a lot of information, so let's go over the important points to keep in mind. One, talk to people with disabilities to inform your product vision. Two, learn assistive technologies from the experts. And three, build a better experience for all users and potentially capture more market share. Now, I'm going to hand it over to Catherine, who's going to go over stage two, design. CATHERINE IDYLLE: Right here. ANDREA WONG: Oh, you're right here. CATHERINE IDYLLE: Thanks, Andrea. [APPLAUSE] Hi. Now that you've defined your product vision, it's time to design your app. At this stage, you'll need to think about interaction design, visual design, UX writing, and motion design. But don't worry. We'll do a design challenge together using our fictional app, Crane, to learn how to do this. So Crane is a travel and hospitality app that lets users book flights and accommodations on a computer or phone. In terms of interaction design, you might be wondering, how do I even get started design accessible and usable experience for everyone? Well, design as you normally do. Have your wireframes and your sketches, and we'll get started there. This is a wireframe of filter options on mobile when you search for a flight on Crane. Here, we can see that the checkboxes are aligned with the label, but they're pretty far apart. When designing your layout, ensured that related content and controls are grouped together. This makes it easier to understand and also easier to reach for people with motor disabilities, especially for people with ALS or a traveler on a bumpy train. So what we did here is that we placed the checkboxes right next to the labels. It's just a better experience for everyone. In terms of interaction design, you can also have a huge impact on all users by thinking about the tab interaction model, meaning a great keyboard experience. Here, we have a wireframe on web of the flight search results. Tabbing on the keyboard allows you to jump from one interactive element on the screen, as we can see right here. This would be the default tab experience if we didn't design it at all. It would take 94 tabs stops to go from point A, the back button, to point B, the filter options. This is a slow experience. So what we can do is actually group major elements together, like this list of individual flights. Now, it only takes seven tab stops to reach point B. And once you've grouped your big tab stops together, don't forget how to quickly navigate to those smaller elements, such as the individual flights in this big list of flights. Here, we'll go with an up and down arrow option to navigate between them. Overall, this is a much better and productive experience for power users, much like yourselves right here, and assistive tech users alike. Here are some things you can do to make your app more accessible in terms of interaction design. Group your content and your controls together. Design your tab interaction model. And don't forget the error navigation as well. Now, onto Bethany to talk about visual design. [APPLAUSE] BETHANY FONG: Thanks, Catherine. So now that we've laid a good foundation in terms of interaction design, let's refine our visuals. Now, to start with the very basics, I'm sure you all have felt the pain of viewing light gray text on light gray background. Let's not put our users through that. So the number one way that you can be a hero for these users is by ensuring that color contrast is-- between your foreground and your background colors is going to be high enough. And you can use our material color tool, pictured here, to check the legibility of your choices and check them against different background colors, like the three shades of purple here that we were exploring for the Crane app. So let's apply this. Going back to our app, where the user is filling in their information to purchase their flight, these faded colors that you see are trendy, but the contrast is so low that it's hard for even most sighted users to have a legible experience here. And remember, this is going to be better not just for users with low vision but someone with dilated eyes after a doctor's appointment or people like yourselves, out in the sun all day with glare on your screen. So let's add more color contrast. First, we're going to zoom in on how we can add contrast into the text field component. We increase the font weight and color darkness in the text fields, which makes it easier to scan and ensures a better visual hierarchy. And we also increase the background color darkness on the button at the bottom, making the text more legible and making the call-to-action much easier to spot, which is really important, because you're trying to get your users to purchase something here. And already with the before and after, you can see that this is a much better design. Other than just looking more aesthetically pleasing, the text is more legible. The relative importance of elements is clearer. And the call-to-action are a lot easier to spot. So now, your user is filling in their information into those much better text fields and is getting closer to booking that flight. But it looks like they made an error. Some users can tell because of the bolded orange outline. However, some users with color blindness might miss this important piece of information, and this can be fixed by supplementing any information that's coded in color through other means, like icons or shapes. So we're going to check out the material icon site and search for error icons. It's good to use a central resource like this, because these are common visual metaphors that may be recognizable to a wide variety of users. So it looks like we can go ahead and use this one. So we're going to download it, add it to our text field, and now, there are two ways to understand that this is an error state. And this makes it clearer for everyone, not just users who are color blind. And for our last visual design example, let's look at focus state and element size on screen. So when users choose a seat in this travel app, it's important that they can select the seat that they want and that they know that their selection was successful. And on mobile, this means having a touch target size of 48 dp by 48 dp, or about seven millimeters wide, which is calibrated against the size of an adult fingertip. Makes sense. And on web, try to ensure that your focus is highly visible. You can see it as a bold purple outline around seat 8A. So when you're doing your visual design, when keeping it accessible, make sure that you have high color contrast. Make sure that you have multiple visible indicators for any important component states. And lastly, make sure that your touch target sizes are going to be large enough for people to actually reach. Back over to Catherine. [APPLAUSE] CATHERINE IDYLLE: Thanks, Bethany. I'm back. With writing, you have the power to guide all users with accessible onscreen text, as well as meaningful off-screen text that'll be verbalized by the screen reader. A screen reader is software that sits between you and the application, and it works in tandem with the keyboard. The keyboard moves the focus, and the screen reader will verbalize whatever has come into focus. We have this example from Google.org com, if you heard of it, and it'll read this button as Google Search button. Because a screen reader automatically reads out loud the label, Google Search, and the control type, button. So back to our Crane app. Here we have a checkout screen. It has several interactive elements, but let's just focus on these four buttons. And remember, the screen reader automatically reads out loud the control type. So it'll verbalize these buttons as button, button, button, button. That's problematic. We don't know what the buttons will do, and the council order and complete order actions are right next to each other, which could lead to major user error. Instead, what we can do is add meaningful and concise accessory labels in addition to the default button verbalization. So here, we've added Previous Step, Checkout Progress, Cancel Order, and Checkout Order. Now, we know what each button will do, and there won't be a major gaffe of canceling order rather than completing one, and vice versa. You can be a champion for screen reader users by writing accessory labels in addition to the default verbalization provided by screen readers. In terms of motion design, have you had something important flash before your eyes, blink, and then be gone? Well, this just happened to you and is a major pain point for users with low vision or someone who isn't paying attention. Try to ensure that alerts, like snack bars, are present on the screen long enough so that everyone can see them, like right now, and have an option to easily dismiss them, like dismiss button or a tapping out function. Likewise, consider supporting screen magnification users. Here on web, when a user hovers over a seat, they get additional information about that seat in a hover card, but it covers the rest of the screen when magnified. To help our users get back to whatever they were doing, consider an easy escape hatch, such as an escape key shortcut or a close button. To ensure that your motion design accessible, present alerts for long enough, and have an option to easily dismiss them. Likewise, easily escape hover information during screening magnification. At this stage, we have designed the interactive, visual, writing, and motion aspects of our product. Now, it's time to talk to users. Get some feedback and check if you're on the right track. Also, see if you run into any major blockers you didn't anticipate. Consider running a heuristic evaluation. It consists of having a small set of examiners evaluate your app against known usability principles, otherwise called heuristics. So right here, we have three heuristics from the material design accessibility guidelines, and they're clear, they're robust, and specific. So let's check. Is your app clear, meaning are its layouts non-crowded, and are its calls-to-action visually distinct? Is your app robust? Does it support a variety of user capabilities? Finally, is your app specific? Does it specifically support a variety of user technologies in the ways that the user expects? Let's try this out with Crane. So here, we have two button variations, and we want to see if it's clear enough for low-vision users. Well, we may find that these two buttons actually have the same color contrast. But we may also find that people prefer the one on the right, because the shopping cart icon makes the purpose of the button more obvious for people with and without disabilities. After you're completing your product, conduct a heuristics evaluation, and feel free to use the accessibility guidelines provided by material design. Is your app clear, robust, and specific? Now, back to Bethany on how to develop your app. BETHANY FONG: Thanks, Catherine. [APPLAUSE] So you've moved on to the development stage. And you'll want to make sure that all of those decisions you just made in the design stage pull through to the final product. So the first thing you can do is use standard components when designing. If you use material components, that will be pre-vetted, work well within a holistic design system, and they'll be usable and recognizable to your users. If you do something nonstandard, note that you'll perhaps have to design the full component yourself, as well as marking it up with the appropriate metadata, particularly for screen reader users. You'll need to provide labels, structure, and traversal paths. And designers, one tool that you can use is Gallery, created by Google to help you manage design iterations and get quick design feedback. If you use our material theme editor with Sketch, which is a popular design tool, and upload your mocks to Gallery, you'll automatically see all measurements, or red lines, as designers call them. For example, you can see here how large this price text is and make sure that the touch target size is going to be large enough to be tappable for people with hand tremor. You can also use it to communicate back and forth with your team about accessibility markup and any verbalizations or UX writing that you might want to do. And don't forget to use scalable text. This allows for a piece of text to scale up or down, according to the user's individual settings. This is really important for users with low vision who may have large text turned on, but usually, the rest of the UI remains the same size. So follow the specific platform standards for how scalable text should be implemented. And here's the same screen with the large text now rendered correctly. You can actually read it, which is great. So engineers, you can keep users with various impairments in mind as you code, just as a designer would periodically consider a user with low vision, no vision, or some mobility challenges. And one way of focusing this work is to schedule periodic bug bashes and fix-its from a specifically accessibility point of view. And there's also a number of tools that you can use during development to check your accessibility on web and on Android. These include Accessibility Scanner on Android, which is the app shown here, which is really easy to use, because it checks your app screen by screen for any accessibility errors. And come by the Accessibility Sandbox during I/O to speak for engineers to learn about other dev tools that you can use during your own process. So as you're developing, don't forget to use common components when you can and just inherit the work that we've already done for you there. Use scalable text, and use accessibility development tools throughout your process to check yourself as you go. All right. ANDREA WONG: Thanks, Bethany. So now, I'm going to talk about the last stage, stage four, after development. At this point, the bulk of your development work is complete, and you're about to launch. At this time, we recommend using a tool like Pre-Launch Report from the Google Play Store. Some of you may already be using Pre-Launch Report, but the good news is, it now includes accessibility. So upload your app to alpha or beta channel, and it'll crawl through your app to identify a number of ways to improve it, like crashes, latency issues, and, of course, accessibility. And you won't need to instrument your app ahead of time. For the web, we recommend automated accessibility tools that's built right into our Chrome DevTools. So inside the Audits panel, you'll see a tool called Lighthouse. Lighthouse will run about 40 automated tests against your site to check for common accessibility issues. When it's finished, it'll give you a score. It'll point out the failing elements. And the best part is, it'll link you to documentation with instructions on how to fix those failing elements. And if you've done everything right up to this point, if you've listened to all of us, then everything here should be a breeze. One more thing-- no great onboarding experience is complete without good help content. And help content is a resource that people with disabilities often utilize. So make sure you include in help content on accessibility, and make sure that content is actually accessible. This is a great opportunity to help all users get off to a great start with your app or your product and recover quickly when they get stuck. Yay, you've launched. Now that we're here, you're probably going through your metrics, your analytics. You're checking the effectiveness of your launch, the user engagement, and so forth. You're hopefully also doing user studies, and you're measuring satisfaction to see how well your app is being received by everyone. At this point, include respondents with accessibility needs so that you're hearing all the feedback. This is also the perfect time to stop and understand what benefits your team has reaped from design inclusively from the very beginning. So here, do a post-mortem. Decide what to cut, what to keep, what to change, and apply that to your next cycle. Over time design inclusive will become second nature to you. Let's go over the main points. One, check for common accessibility issues with Pre-Launch Report and Lighthouse and countless other tools out there. Make sure you have accessibility help content that's accessible. And get feedback from users with disabilities. And now, Jen will summarize all this for us. JEN DEVINS: Thank you, Andrea. All right, so there you have it, our tool kit of ideas that, hopefully, you can apply to your process. We know it's a lot of information. There's a lot of great resources out there that you can rely on. We wanted to leave you with one thing you can do during each stage of the process starting today. So if you're starting out and you're defining your product vision, can't stress it enough-- get out there and talk to users. If you're curious of, where should I find users with disabilities? I don't know anyone. There's lots of organizations nationally and internationally that you can reach out to, and they'll often put you in contact with their members. And in fact, today in the Design and Accessibility Sandbox across the way, there are members from the National Federation of the Blind that are willing and wanting to give you feedback or just answer your questions. If you're in the design stage, you probably started working on your interaction workflow model, and you're thinking about it, have it drafted. Before you get too far, take a step back and think, now, how would a user that's using just a keyboard go through this interaction model? How would they get their task done? This is a great place to start, and you'll be very happy you did this earlier than later. If you're in the development stage, use standard components. They've been stress-test, and they're familiar to users, which is great. You don't want users to have to relearn their app for each screen. And finally, if you're nearing that finish line and it's after development, just as Andrea mentioned, we really recommend ensuring that you have accessible onboarding and help content and, if it makes sense for your app, to have accessibility-focused tutorials and onboarding material. Making inclusive products is critical. We all have the power and responsibility to remove barriers and empower all users to be productive and connected. [MUSIC PLAYING] Thank you so much for your time. [APPLAUSE] [MUSIC PLAYING]
Info
Channel: Google Developers
Views: 34,701
Rating: 4.9670587 out of 5
Keywords: type: Conference Talk (Full production);, pr_pr: Google I/O, purpose: Educate
Id: TAzkrXTGEOM
Channel Id: undefined
Length: 36min 30sec (2190 seconds)
Published: Thu May 10 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.