Speaker 1: ♪ Hi, I'm Alex.

Speaker 2: Hi, I'm Shu, and we are UX designers on the YouTube Ads team. Today, we're going to talk about getting started with accessibility and product inclusion. Before we jump in, I want to ask you, have you ever felt lost at an international airport with confusing signs around or a language you don't understand? Have you ever felt excluded when shopping online but you can't find a product that matches your size or style? As a developer, I'm sure you have a vision for why you build things. Maybe you want to create something useful that makes people feel empowered or something delightful that brings more joy in people's everyday life. While we often focus on the question of who we are building for, to reach as many people as possible, I want to challenge you to think about who you might have unintentionally excluded today in your product. To start with, Alex is going to discuss assistive technology and testing for accessibility. Then I will talk about product inclusion and how to start integrating it into your development process.

Speaker 1: I don't know if you've ever seen A11y. I know that the first time I saw it, I had no idea what it was. But it's just a common abbreviation for the word accessibility with 11 letters between the A and the Y. And accessibility is the practice of making products, environments, and social structures usable and inclusive to people with disabilities. So according to the World Health Organization, more than one billion people have some type of disability. That's not one in a thousand. That's 15% of the global population. And when I say disability, take a second. Think about what image comes to your mind. Now I want to expand what your idea of a disability might be because they aren't always visible or permanent. While some disabilities are easy to see, that's not always the case. For example, if the woman on the right has dyslexia, would you have guessed that? It also reminds me of my grandma, who's extremely hard of hearing, but it's not at all obvious just by appearances. Disabilities can also be temporary or situational. For example, the person on the left might use a wheelchair because of a permanent disability. The girl in the middle might only be using a wheelchair for a few months due to a badly broken leg. And I was actually in that exact situation when I was nine after a very bad first attempt at ice skating. And the man on the right pushing a moving cart might only situationally have trouble moving around. And if you've ever had to move a bunch of boxes yourself, I'm sure you can relate. A curb cut would benefit all three of these groups, even though curb cuts were originally added just for people with permanent disabilities. And this is just one example where building for accessibility has benefits that ripple out to everyone. This is true for many features we take for granted today, like if you've ever relied on video captions or automated captioning on video calls. There are many different types of disabilities, even more so when you include temporary and situational ones. So to help you focus where you put your efforts, you might categorize disabilities into vision, hearing, mobility, and cognitive disabilities. For many of those with disabilities, they rely on assistive technology, which you may see abbreviated as AT. They're tools that help increase, maintain, or improve functional capabilities of individuals with disabilities. Like my grandma, to help with her hearing, she uses hearing aids. And we've also been trying out the Live Transcribe app on her Android phone to make conversations a little easier. Some common assistive technologies are keyboard, maybe if someone's unable to easily use a mouse, switch device, perhaps if someone has limited hand dexterity, screen readers, primarily for people who are low vision or blind, braille readers for people who are deafblind, and voice control if someone's unable to physically interact with a device. And there are many more technologies and use cases, and we can't cover them all today. But how do you build for all of these technologies? It may seem overwhelming, but they rely on the same underlying metadata and APIs. So if you focus on building for keyboard navigation and for screen readers, you'll address most of the other assistive technologies. With that said, let's jump into a demo of keyboard navigation and screen readers. You're probably already familiar with keyboard navigation. If I hit the tab key, I move my focus to different interactive elements on the page. There's a focus indicator to help me see which element is currently focused. If I focus on the text input, I can type into it. I can hit space to toggle this checkbox. And some other elements may use arrow keys, space, or enter. And I'll hit enter to submit the form. And it automatically moved my focus to the email field because I didn't fill it out even though it's required. And I can use shift tab to go backwards in the focus order. Moving on to screen readers, the ones available to you depend on what systems you're using. So I recommend you do a quick search for your operating system screen reader. I'll be demonstrating the ones included in Android and Mac today. While there's a lot of available commands, all you really need to know is how to turn it off and on, how to go forward and backwards, and how to activate an element. I used command F5 to turn on my Mac screen reader. And I'll use control option right to move forward.

Speaker 3: Navigation. You are currently on a navigation inside of web content. List four items. Link. Oddities. Link. Entertainment. Link. Lifestyle. Link. Technology. 404.

Speaker 1: It reads the text on screen, but also metadata, instructions, and page structure.

Speaker 3: You are currently on a link. To click this link, press control option space.

Speaker 1: Even if I'm not able to see this image, description helps me understand what that image is about.

Speaker 3: A large brown bear. Image.

Speaker 1: I can use control option space to activate elements, like toggling this checkbox.

Speaker 3: Required invalid data unchecked. Required checked.

Speaker 1: And activating the submit button.

Speaker 3: You are currently on a button. To click this button, press control option space. Please fill out this field.

Speaker 1: And I can use control option left to move backwards.

Speaker 3: Email. Alex. Insert name. Heading level 2. Subscribe to our newsletter. You are currently on a heading level 2.

Speaker 1: For Android to turn on the screen reader, I'll need to go into my settings. So I'll open the system settings. Accessibility. And TalkBack. And I want to turn on the TalkBack shortcut, so I can quickly turn it on and off without coming back into the settings. For me, I hold down both volume buttons.

Speaker 3: TalkBack on.

Speaker 1: Now, I can swipe right to move forward.

Speaker 3: Succulent. Heading. Rectum area. Titubines.

Speaker 1: I can double tap to activate.

Speaker 3: Keyboard. L, O, B, E, I, I, T. Navigation bar.

Speaker 1: Double tap again. And I can turn it off by holding my shortcut, which is both volume buttons. So now that you know the basics of assistive technology, you may be wondering, how do I figure out what accessibility issues I have? For that, consider a combination of automated and manual testing. Automated testing tools can help you catch about 57% of accessibility issues, according to a study by Deque. These can be integrated into your automated tests. But for the scope of this introductory talk, we'll just go over two interactive tools that you can get started with pretty fast. On Android, we'll check out the Accessibility Scanner app. And on desktop, we'll use the Chrome Lighthouse DevTool. All right, let's jump into a demo, starting with Android. If I want to check the accessibility of this page, and I already have the Accessibility Scanner installed, I'll open the Scanner app. And I have to enable it in System Accessibility Settings. And we'll give it the permissions that it needs. Back in the app, there's a floating checkmark button. If you tap onto that, you might have to grant it some more permissions. Tap the checkmark button, and I'll take a screenshot of this page. And it's telling me that it found five accessibility issues. The text contrast is too low. The button's too small. The icon button has no label. The field isn't tied to its label correctly. And buttons with duplicate text are harder for screen readers to differentiate. I can see a list of all the issues, more detail about an individual issue. And I can share a zip file of all the information here to another device or person. Back on desktop Chrome, I'll open the DevTools, go to the Lighthouse tab. And Lighthouse can test for multiple categories of things, but we'll just focus on accessibility here and for desktop. I'll generate a report, and it'll take a few seconds to test that page. And it's giving me a list of accessibility issues that it found. So the image doesn't have alt text for screen readers. The text input isn't tied to its label correctly. The page doesn't have a title. And the text at the top is too low contrast, so it's difficult to see. But remember that automated testing can't catch every accessibility issue. For example, this text might look like a heading, but it's not using the appropriate heading element. This makes it harder for some users to navigate your page.

Speaker 3: You are currently on a text element inside of Web Content. To exit this web area, press Ctrl, Option, Shift, up arrow.

Speaker 1: These buttons seem out of order, and they aren't following the logical or visual order of the page.

Speaker 3: First button. Second button. Third button. You are currently on a button.

Speaker 1: And I actually can't focus this last button with my keyboard. This means that parts of your product might be totally impossible for some of your users to use.

Speaker 3: Looks can be deceiving. Empty group.

Speaker 1: And this is a div that I've styled to look like a button, but it's not announced as a button, so I may not know that it's interactive.

Speaker 3: You are currently on empty group inside of Web Content.

Speaker 1: And it would be a lot of work to reimplement that button accessibly when I could just use the standard button element instead. So I hope I've convinced you that automated testing won't solve all of your problems, and that pairing it with manual testing can help you find more issues. Consider starting with identifying the main tasks of your product and try to complete those tasks using just a keyboard and then with a screen reader. And you may be wondering, how do I figure out everything that I should consider testing for? With this testing, a good place to start is the Web Content Accessibility Guidelines, abbreviated to WCAG or WCAG. The entire WCAG document is really quite long, so don't worry about reading it all at once. When you run automated testing, the results will usually point you to specific WCAG rules. So to summarize my recommendations on how you can get started today. One, get familiar with assistive technologies. Try using keyboard-only navigation and a screen reader. Two, audit your product through automated and manual testing. Then you can prioritize the issues, probably tackling the simplest ones first and then learning how to fix them one at a time. Three, fix your bugs. Refer to WCAG and bug details on how to fix them correctly. And if you're building something new, consider bringing accessibility earlier in the process when you're planning and designing. Accessibility is an important piece of creating a more inclusive product. And to talk about inclusion more broadly, I'll hand it over to Xu.

Speaker 2: Thanks, Alex. We just talked about accessibility. Now, let's take a look at what is the relationship between accessibility, inclusive design, and product inclusion. Let's take a look at this diagram. While accessibility is focused on a specific attribute, inclusive design is the methodology to create products that understand and enable people of all backgrounds and abilities. It generates inclusive design patterns and helps us understand complex intersectional needs. Product inclusion is broader. It is an end-to-end product development process that considers inclusion at many touch points. To center historically underrepresented voices and create better solutions for everyone. Now, what does inclusion mean to users? When we think about an inclusive paradigm, there are many dimensions to diversity. From race, gender, age, to disabilities, physical attributes, and more. While accessibility focuses on making products usable and inclusive to people with disabilities, all of these dimensions need to be considered and represented. Meanwhile, these dimensions can meet and overlap. Their fluid can adapt and evolve as a person gets older. Here is what we learned from our recent qualitative survey with YouTube users located around the world. Inclusion means representing people of all backgrounds. Let's take a look at what our users have shared and what inclusion means to them. Inclusion is when you are accepted, no matter how you are or who you are. It shouldn't make you feel like you have to fit into this one stereotype in order for the product to apply to you. It needs to encompass all races, all genders, and at the same time, not make you fall into a specific group. To sum it up, inclusion means feeling like people of all types are represented in a fair and real world way. So why is product inclusion important? Product inclusion isn't just the right thing to do. It is also a framework that can help you design useful, accessible products for large untapped audiences. There is so much we can do proactively when we understand trends in growing markets. These communities, which may currently be underrepresented online, are growing fast. For instance, research shows that between 2015 and 2016, U.S. Latinx usage of mobile apps grew 48%. We know from research that companies that get product inclusion right are going to build sustainable value for users. In addition, when we build with inclusion in mind, outcomes are often better for everyone. For instance, closed captions technology was invented for people who are hard of hearing. Now it is also used by people in loud airports and can help children who are learning to read. So how to start integrating product inclusion into your product development process? First, I'd like to share with you an example of how we started to uncover product opportunities via workshops. We organized our very first product inclusion workshop, invited subject matter experts and cross-functional partners to learn about inclusivity and brainstorm product ideas on how to make YouTube ads more inclusive. One thing we learned that can make a workshop, especially a brainstorming session, effective is to create user scenarios or themes to help your participants narrow down the focus. For example, we had three breakout groups, each assigned with different diversity dimensions to tackle with. It turned out that workshops with a good balance of individual idea generation and team collaboration can be quite helpful for uncovering opportunities to make your product more inclusive. Here is an example of a product idea evolved with inclusive lenses on. Melody loves beauty and fashion. One day, she ran out of her foundation and went online searching for best liquid foundation with a wish to try some new products. However, at a first glance of the results, she didn't see anything that matched her skin tone. She felt left out. Now, what if we consider the diversity in skin tone and enable users to easily access products that closely match them? Imagine Melody sees products in the context of her own physical traits and feels her beauty is celebrated. This is just one example of how inclusive thinking can potentially translate into a better product experience. There's so much more we can do. Second, product inclusion is not a one-and-done project. We have learned that it is an end-to-end process that considers inclusion at many key touch points, such as ideation, UX research, design, testing, and marketing. By bringing in diverse perspectives early on during ideation phase to ensure we are not just building for ourselves, by getting to the core of what the user needs are and what challenges we're trying to solve through user research, by testing a myriad of potential users once the product or service is created. Overall, opportunities to bring in more historically underrepresented voices exist across the entire product development lifecycle. And you can start today by understanding your process and identifying opportunities to intentionally bring in the inclusive ones. Last, product inclusion is not merely a box to check. It is a mindset and a culture of commitment to build product for underrepresented users. There are many ways to start driving this culture shift with your team. For example, encourage discussions about inclusivity, by asking questions like, who might we be unintentionally excluding today in our product? Also, build products with historically underrepresented users by recruiting customers from underrepresented communities to participate in your design sprints and product testings. At the end, let's stop thinking about accessibility or inclusion as edge cases and start intentionally integrating it into your everyday work. Because working on product inclusion doesn't just mean that you are making your product more inclusive for historically underrepresented people. It means you are building a better product for everyone.

Speaker 1: If you want to learn more, we've linked to helpful resources plus an accessibility video series called Alleycasts. I hope we've motivated you to take action on accessibility and inclusion. We want to encourage you to just try it, put something out there and get feedback. You may not get it right on your first attempt, but you will get there. It just takes some time. Even experts don't know everything and aren't right 100% of the time. But your users will notice and appreciate that you're making an effort. So take that first step on getting started with accessibility and product inclusion. www.microsoft.com