Guest: Laura Allen, Accessibility Program Manager at Google
In the last two episodes of Build, we tackled why accessibility needs to be prioritized in product design and the three key tips that are critical and will make a big impact on your product adoption.
This week, we’re going to answer two questions that inspired this series from one of our audience members, Jane. We chose these two because we figured they might also be on your mind!
Jane wrote:
Poornima,
Thanks for tackling a wide variety of topics when it comes to building software products. One area that I’m curious about is accessibility.
As a user experience designer, I know accessibility is important, but I’ve struggled when it comes to balancing out accessibility across devices and also making mobile apps interactive and fun without compromising on accessibility.
How should I go about thinking about web versus mobile and balancing out fun and engaging interactions with accessibility in mobile apps?
Sincerely, Jane
Jane, thank you for writing in!
Laura Allen—Accessibility Program Manager at Google for Chrome and the Chrome operating system—is back, and together we are going to answer Jane’s questions in today’s episode.
As you watch today’s episode, here’s what you’ll learn:
You can listen to this episode of Build on iTunes. Please take a moment to leave us a review. Your positive review will help us get featured in News & Noteworthy and bring more exposure to the work we’re doing, as well as the talented guests we feature!
Poornima Vijayashanker: In the previous two episodes of Build, we talked about the importance of accessibility and we shared three critical strategies that will help make a big impact when it comes to building and designing products. If you missed either of those episodes, I’ve included links to them below. In today’s final episode on accessibility, we’re going to talk about what accessibility means across devices for both web as well as mobile. Stay tuned.
Welcome to Build, brought to you by Pivotal Tracker. I’m your host, Poornima Vijayashanker. In each episode, I invite innovators, and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech.
We’re continuing our conversation on accessibility with Laura Allen, who is the accessibility program manager at Google for Chrome and the Chrome operating system. Thanks again for joining us, Laura.
Laura Allen: My pleasure. Thank you.
Poornima Vijayashanker: One of the inspirations for this series on accessibility came from our audience member Jane, so I’m going to start off today’s episode by reading the question that Jane posed. Jane wrote, “Poornima, thanks for tackling a wide variety of topics when it comes to building software products. One area that I’m curious about is accessibility. As a user experience designer, I know accessibility is important, but I’ve struggled when it comes to balancing out accessibility across devices and also making mobile apps interactive and fun without compromising on accessibility. How should I go about thinking about web versus mobile and balancing out fun and engaging interactions with accessibility in mobile apps? Sincerely, Jane.”
Jane, if you’re tuning in to this episode, thank you for writing in. Laura, why don’t we start by answering Jane’s question to begin with. How do we balance out web versus mobile?
Laura Allen: It’s a really great question. When you think about it, a lot of these concepts that we were talking about in previous episodes are actually going to stand true no matter what platform you’re actually designing for. Think back to the web content accessibility guidelines, WCAG. They talk about perceivable, operable, understandable, and robust, and those sorts of concepts and principles that go within each of those categories. Just taking one example, color contrast. Color contrast, having really solid contrast between text and its background, that’s important no matter what device you’re on. It’s going to be the same sort of truth for if you’re on a mobile phone or if you’re on a desktop computer. A lot of these concepts are going to just span across platforms and be really relevant for you to consider.
One thing that’s obviously a little bit different on mobile is that it’s clearly more touch oriented for most users. Things like touch targets and the size of your touch targets, that’s important to consider. Some people might not have as precise motion or control as they’re using their phone or tablet, but honestly, the lines are getting a little bit blurry anyway. Think about all the different devices that are out there now, like laptop computers that also have touch screens or convert and are then used in tablet mode. As designers, we’re starting to think about, “How do we just make an app itself accessible on all these different platforms, or a site itself?”
Poornima Vijayashanker: Let’s tackle Jane’s second question on how do we balance out fun and engaging interactions versus accessibility.
Laura Allen: Yeah. That’s another really great question. I think something that we should keep in mind when developing for mobile is sometimes we just rely a little bit too heavily on this idea of gestures and touch-based interfaces. I understand why, of course. It’s typically being used by using touch. Some users aren’t able to actually use touch to operate a phone. There’s something called switch access, for example, which basically allows you to pair a one-button, or two-button, or multiple-button switch and control a phone just using those external buttons. That’s just one example. Some people might be only using voice to control a device. Some people might be navigating with a screen reader, so as something flashes on the screen, they’re not able to actually perceive that and then catch it in time to actually take action. Thinking about what are these things that we’re assuming our users can do here, and then offering alternative ways to actually operate.
For example, if you have an app that you’re building where you have cards that you need to swipe away to take action, a swipe can work for some people, but for others, maybe that’s not going to be possible. How do we think about things like, “OK. Can we add a hidden close button here so that a screen reader could actually access that and somebody could just simply double tap to activate?” Lots of different things like that. Just, again, removing assumptions about how our users are interacting and then just building to cater to different groups.
Poornima Vijayashanker: I think your answers are going to be very helpful for Jane and the rest of our audience. Any final words of wisdom that you’d like to share when it comes to accessibility?
Laura Allen: Sure, yeah, a couple things. First, just thinking again about mobile versus desktop and web and what not, I think it’s also really helpful when designing for mobile to be thinking about the platform-specific guidelines. This is like guidelines for more so just the interaction models for that platform. I know there’s the Android developers resources and site. iOS has the iOS human interface guidelines. These things obviously go well beyond just the concepts of accessibility, but they’re really important to keep in mind because if you think about it. One example of what would be discussed is focus management. When you first open up an app, where is focus meant to go? What is the default? As you think about these concepts that are kind of illustrated through guidelines for each of these platforms, it’s really helpful to keep that consistent so that when a user who happens to be using assistive technology interacts with this app, they get a similar experience to what they’re used to. It’s a similar model for them, and therefore it’s an easier ramp-up curve to actually get introduced to your design. That would be one suggestion.
Another thing to consider, which we haven’t really discussed at this point: We talked a lot about auditing and integrating accessibility into your processes, and a lot of what we’ve talked about so far has been manual testing and the importance of really diving in, trying out the keyboard-only experience, or trying out a screen reader. Absolutely, I think that is so critical. I think honestly…I often get asked about manual versus automated testing, like what can we put in place to run automated tests. There are some great things to do, so there are automated tools, like, for example, there’s a tool, there’s an Android app called the Android Accessibility Scanner. It’s free. It helps to run an audit of your app’s accessibility and show you the results for things.
Poornima Vijayashanker: Oh, great.
Laura Allen: Yeah. For things like missing labels on a button or color contrast, things like that, which I would imagine to be kind of low-hanging fruit that you look at and hopefully fix rather quickly. There are similar things on the web and desktop. Lighthouse is a great tool, which integrates with the Chrome Developer Tools. There are lots of other types of tools out there that you can leverage to do some automated testing and audits, but in my opinion, automated can only go so far. That’s where you use it to kind of see a baseline, track progress over time and your results, but manual is really critical. Again, whether it’s you going through or having assistive technology users go through and give you feedback, that’s where you’re going to capture that more human interface experience. You’re going to understand what is the usability of this product, whether on mobile or on desktop. It’s just really critical to find that right balance of manual versus automated testing.
Poornima Vijayashanker: This has been wonderful, Laura, and we’ll be sure to include all the resources you mentioned below so that our audience can make sure to get access to them.
Laura Allen: Great. Thank you so much for having me.
Poornima Vijayashanker: Yeah, yeah. You’re welcome. This has been great.
That’s it for this week’s episode of Build. Be sure to subscribe to our YouTube channel to receive more episodes like this, and be sure to share this with your friends, your teammates, and your boss. A thank you to our sponsor, Pivotal Tracker, for their help in producing this episode. Ciao for now!
This episode of Build is brought to you by our sponsor, Pivotal Tracker.
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
