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's 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 think 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 who is the Accessibility Program Manager at Google for Chrome and the Chrome operating system is back and together we are going to be answering Jane’s questions in today’s episode.
As you listen to today’s episode you’ll learn:
What are the similarities and differences when it comes to designing for accessibility on web versus mobile devices
How to balance balance out fun and engaging interactions versus accessibility on mobile devices
The various types of accessibility testing: manual versus automated and tradeoffs associated with both
Here are links to the resources Laura mentions in the video:
--
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
--
## How To Balance Accessibility And Interactivity Across Devices Transcript
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.
Wasn’t last week’s episode on accessibility in product design enlightening? Well get ready for more!
The goal of the last episode was to give you solid understanding of accessibility, and all the things you could think about when designing a product with accessibility in mind. But we understand it might be a lot to tackle, which is why in today’s episode we’re going to boil it down into 3 key tips that are critical and will make a big impact.
Laura Allen is back to enlighten us. Laura is the Accessibility Program Manager at Google for Chrome and the Chrome operating system.
As you watch today’s episode you’ll learn:
Here are some additional resources to checkout that Laura mentioned in the video:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
## 3 Key Tips To Keep In Mind When Designing For Accessibility Transcript
Poornima Vijayashanker: In the previous *Build* episode, we talked about the importance of accessibility. If you missed that episode, I've included it below. Now, in that episode we talked about a number of things that you could do to improve your product. In today's episode, we're going to boil it down to the three main things that you want to think about when you're designing and building your product, so 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 today on accessibility with Laura Allen, who is the accessibility program manager at Google for Chrome and Chrome operating system. Thanks again for joining us, Laura.
Laura Allen: Absolutely. Thank you for having me again.
Poornima Vijayashanker: Yeah. Last time we talked about a number of things that our audience can do when they're thinking about designing products or revisiting their products and incorporating more accessibility. In today's episode, I want to focus solely on the top three things you think are super critical and will make a big impact in people's products.
Laura Allen: Great.
Poornima Vijayashanker: So, let's start with the first.
Laura Allen: First.
Poornima Vijayashanker: Yeah.
Laura Allen: OK, so I would say the first thing to do is to train your team.
Poornima Vijayashanker: OK.
Laura Allen: Thinking about accessibility, it's not just one person's job, and that's something really important to keep in mind. This is a full team effort. There are different roles that different people have to play from design to research to development to just release processes, all of those different things. Everyone needs to play their individual part, to be totally honest with you. A lot of teams just will honestly benefit from just going through different trainings, leveraging resources that are out there. There are a lot of great things, like for example, I know a few of my colleagues actually have put together this awesome Udacity course just all about web accessibility. That's a great resource. There are lots of videos out there. There's this great YouTube series called The A11y Casts, it's like A-11-Y, which is an abbreviation for accessibility. If you've seen that before, it's A, 11 characters, Y, mean accessibility. So, lots of different things out there. We can definitely link some resources for sure.
Poornima Vijayashanker: Yeah.
Laura Allen: I would say, yes, training the team. Make sure everyone feels comfortable with the concepts of how to start building this in. That will go a really long way.
Poornima Vijayashanker: Nice. So, it's not just to put the onus on the designers of the team but really your PMs, your engineers.
Laura Allen: Exactly. Thinking about, for example, like the designers when you're scoping out a project, let's incorporate accessibility into design docs. Think about, "OK, well what should the keyboard model actually look like?” just as one example. "What should contrast? Am I thinking about contrast in my mocks?" So, bringing it in at the design phase, and then basically working with your engineers as you’re developing, testing for accessibility as you're going along, having PMs to help make sure that that process is happening, it's being managed all the way through. I think it's really critical. Basically, having everyone ramped up on this, everyone understand the fundamentals is really key.
Poornima Vijayashanker: Wonderful. What's tip number two?
Laura Allen: Yeah, so tip number two would be to integrate accessibility. Honestly, I understand why a lot of people might get to the end, be ready to release a product, maybe even release it, and then say, "Oh, shoot. We forgot about accessibility."
Poornima Vijayashanker: Yeah.
Laura Allen: Maybe they'll get bugs filed against them. That's not the situation that you want to be in. It's also just not an inclusive way to be building your products. I think just working hard to integrate into each step of the way, and that's what's helpful to have each different role on your team understand accessibility, of course. So, integrating so that when you're preparing to launch a product, that's at the phase. When you're actually designing and building it, that's when you're working on these concepts and implementing these principles instead of, "OK, we're ready to go. We're going to launch," and then, "Uh-oh."
Poornima Vijayashanker: Yeah.
Laura Allen: So, integration.
Poornima Vijayashanker: What's the third and final most important thing people should consider?
Laura Allen: Yeah. I would say to engage the users.
Poornima Vijayashanker: OK.
Laura Allen: This is something that's really important, again. So, just understanding how...read a list of technology users or just users with any variety of accessibility needs are interacting with your product. One really simple step that I think is, if you're going out and you're conducting user research in the first place, why not add somebody who's an assisted technology user right to that pool? Add someone who's a screen reader user or someone who can only use the keyboard, for example, and can't use a mouse. Try to diversify that pool, and make sure you're collecting that user feedback, and understand how your product is working for a variety of different users.
Poornima Vijayashanker: Very nice. Yeah, keeping the user in mind. Are there places that you can try to recruit from? A lot of people might use something like user testing and there's a few other services out there, but anything you would recommend to recruit people?
Laura Allen: Yeah. I mean, one thing that I know we've seen a lot of success with is partnering with organizations. Just as one example, we're here in San Francisco today, the San Francisco Lighthouse for the Blind and Visually Impaired, that's just one example of a fantastic organization where they're more than happy to partner with teams or with individual researchers just to give feedback. They want to be helping. They want to make these products even better and better. There are lots of different types of organizations that are similar to that, which maybe local for people who are not right here in San Francisco, also national organizations, international organizations. So, just thinking about how do you leverage different communities, and you'll find that oftentimes if you just kind of approach different people and say, "Hey, we'd love your feedback on making this better and making it work better for you. Can you help us out?" It helps if you're going to go and have one of those conversations if you've thought through some of these core concepts and some of the things that are mentioned in the WCAG Guidelines, and you're not showing up without having even considered accessibility. Right? It goes a long way to bring real people in, real users in, and just make the products that much better.
Poornima Vijayashanker: Well, thank you so much, Laura, for boiling these down into three useful tips. I know our audience is going to get a lot of out this.
Laura Allen: My pleasure. Thank you so much.
Poornima Vijayashanker: Now, Laura and I want to know, have you tried one of these three tips when it comes to incorporating accessibility into your product, which of these did you try, and what was the impact it made? If you've got others, be sure to include them in the comments below. That's it for this week's episode of *Build*. Be sure to subscribe to our YouTube channel to receive the next episode, where we'll dive into incorporating accessibility into web versus mobile. Special thanks 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.
It’s a new month and with it a brand new theme for our upcoming Build episodes! When designing products we often think about usability: how easy to use a product is. But we often overlook another aspect of product design: accessibility. So all this month we’re going to dive into accessibility.
One reason accessibility gets overlooked is because we think it’s a challenge to prioritize it given a company’s size and resources. We may think accessibility makes sense for a big company, but a startup that is getting off the ground just doesn’t have the resources to incorporate it.
Well, actually that’s not true...
In fact, accessibility maybe just the differentiator you need when it comes to product design that is going to give your product a competitive advantage and increase adoption!
And in today’s episode, we’re going to explore what accessibility is, why it’s important for any size company to incorporate, and show you how to do an accessibility audit for your product.
To help us out, I've invited Laura Allen, who is the Accessibility Program Manager at Google for Chrome and the Chrome operating system.
You’ll learn:
Here are some additional resources to checkout that Laura mentions in the episode:
Build is produced as a partnership between Femgineer and Pivotal Tracker. San Francisco video production by StartMotionMEDIA.
## Product Design: Why Accessibility Needs To Be Prioritized In Product Design Transcript
Poornima Vijayashanker: We often think about usability when we're designing products, but not accessibility. In today's *Build* episode, we're going to talk about the importance of accessibility and how to prioritize it regardless of being a startup or a big company, so stay tuned.
Welcome to *Build*, brought to you by Pivotal Tracker, I'm your host, Poornima Vijayashanker. In each episode of *Build*, I host innovators and together we debunk a number of myths and misconceptions related to building products, companies, and your career in tech. Now, one often overlooked aspect of building products is accessibility. In today's *Build* episode, we're going to talk about what accessibility is, why it's important, and how you can do an accessibility audit for your product. To help us out, I've invited Laura Allen, who is a accessibility program manager at Google for Chrome and the Chrome operating system.
Thanks for joining us today, Laura.
Laura Allen: Absolutely. Thank you so much for having me.
Poornima Vijayashanker: Sure. I know that a lot of times people think about usability when they're building products but they don't often think about accessibility. Let's talk about what is accessibility and how is it different from usability.
Laura Allen: Accessibility is the design of products, services, devices, and environments for people with disabilities. I always like to take that one step further and think about accessibility as really empowering users with disabilities to be productive, to be socially engaged, and to be independent. This is super closely aligned with the concept of usability and also even just universal design and inclusive design. You think about universal design being this idea of building products that are going to be usable by the widest range of people and the widest range of situations. It's so closely aligned with this, that absolutely includes designing for people with disabilities.
This whole concept of usability, yes it's critical to be thinking about all the time, of course, but we can make products functionally accessible, we can go through checklists, we can incorporate design principles and what not to make things technically work, but if you don't think about how is this actually going to be used, what is the experience for someone with assistive technology—like a screen reader, for example—if you don't think about that experience and usability of that experience it might not be productive or efficient at all. All these things are really closely linked together and they all help to move towards building an inclusive product.
Poornima Vijayashanker: Why is this even important? I think a lot of people would say, "Oh, we have a really niche customers customer base, we don't think anybody has accessibility concerns so why even bother?"
Laura Allen: Accessibility is something that impacts everyone at some phase or at some point in their life. Fifteen percent of the global population has some form of disability—that's a huge number, that's over a billion people. We tend to think about a few different distinct groups when we're thinking about design. We might be thinking about people who are low vision or blind, people who are deaf or hard of hearing, people who have motor or dexterity challenges. Then people who are, what we consider to be, neurologically diverse that can be anything ranging from dyslexia, to perhaps being on the autism spectrum, to any forms of intellectual disabilities.
When you think about these different groups of people, people might be developing disabilities at different phases of their life, different severity levels, different combinations of disabilities, and then you start to think about, what about temporary impairments? Like what if you break your arm and all of a sudden you can't type on your computer for a few months? Situational impairments, like what if you're at a loud restaurant or a loud bar and there’s something on the TV that you want to be listening to, it's too loud to hear and you have to actually rely on those captions that were there specifically for the deaf population but they're helpful to everyone. Then, you take it one step further, and you think about this growing aging population, which thanks to increasing life expectancy, which is great, the aging population of people over 60 is growing, and growing, and growing, and the World Health Organization estimates that by 2050 it'll be over 2 billion people that are over the age of 60.
Poornima Vijayashanker: Wow, so it's like doubling. Hopefully not, but yeah.
Laura Allen: As we all age, at any point in our lives, we may experience some slight deteriorations in vision, or of hearing, or of dexterity, so these concepts are really, really critical to be building in, in general.
Poornima Vijayashanker: That makes sense. Now, some would say that this makes sense for really big companies with hundreds of millions of users, but does it really make sense for our tiny little startup that's just getting started?
Laura Allen: I would honestly say, accessibility is something that is critical for all companies, at all stages, all phases. To be totally honest with you, it's actually easier to build this in four startup-sized companies, smaller teams, smaller processes. Of course, it's completely doable at large companies as well that have established processes, but at a startup, you're building from the ground up, you're defining what you want your product processes to look like, and it's so much better just to be able to integrate accessibility in at that level, get people understanding what these concepts are, make this just a core part of inclusive design from the very beginning, and it'll be that much easier as you grow, and grow, and grow.
Another thing to think about here is accessibility because it impacts such a large number of people this presents, honestly, a growth opportunity in many cases. It just opens doors for a lot more business, a lot of growth potentially. One thing that I like to think about, especially for startups and just hiring in general, if companies are focused on actually making their own products accessible then it opens the doors as well for being able to hire a more diverse and inclusive workforce. You can hire assistive technology users and have them come in and be able to use your products and that opens the door.
A lot of us, obviously, at the companies we're thinking about how do we further diversify? How do we get people in the room who have a diverse set of perspectives? This whole idea of diversity a lot of times we are thinking about race, and ethnicity, and gender, sexual orientation, but disability is a huge part of this. It is a very, very big part of this group and we need a voice.
Poornima Vijayashanker: Making it into your process, your priorities, your core values can really open doors for you in terms of your customer base and make things, hopefully, easier as you grow.
Laura Allen: Absolutely. I will say, too, for a lot of people, like I mentioned before, accessibility will touch everybody at some point and in many cases it'll make the experience better, and more usable for many, many users. For someone like me, I happen to be low vision myself—
Poornima Vijayashanker: What does that mean, “low vision?”
Laura Allen: Really good question, because it can mean a lot of different things. For me, I basically have a central vision disorder, so if you can imagine all in my peripheral vision is still intact, it's still clear, but anything I'm looking directly at is this blend of flashing lights, and distortion, and blurring, and whatnot. This all happened for me when I was about 14, happened really quickly, really rare condition. I basically went from having typical 20/20 vision to being what's considered legally blind within about a week when I was 14. At that point, it was like I'm getting ready for high school, and all of a sudden I'm going to be moving to a bigger school, and then what happens? I couldn't read a book at that point. I couldn't see a blackboard. I couldn't recognize faces in the hallway. It was a huge period of transition for me, and for my family.
For a few years there, it was one of those things where if materials weren't actually accessible in formats that I could listen to, for example, instead of visually read, I was stuck. I had to literally come home from school and my parents and my brother would read to me. That, to me, was the definition of dependence and I really, really hated it. I was so fortunate to have a family that was able to help me that way. It was just unbelievable the amount of effort they went through to get me through to the point where then I was able to regain my independence through discovering assistive technology like text-to-speech software, or magnification, or a larger mouse cursor, things like that.
It was that period of my life that really propelled me into this world of accessibility and usability, because I saw the huge potential of what technology can do for someone's life and I just want to help to make that better for the rest of the world.
Poornima Vijayashanker: It's great to hear you have a personal stake and it inspires everybody out there, but it also inspires you to realize and relate to people who might also be having these recognitions so that's wonderful to hear.
For people in our audience out there who are building products, how can they get started? How can they prioritize this and gain the benefits?
Laura Allen: That's a great question. There are a lot of different things to be considering. One thing that I would recommend is doing an audit, understanding where is your product right now, what's the level? This may vary. If you haven't really been thinking about accessibility yet, that's OK. It's a good opportunity to look at the holistic picture and see what's going on, and what bugs you may have. I would recommend just going through and leveraging a lot of the different resources that are out there and using those to create your own audit, however that works for you.
For example, there is a great resource out there from the web content accessibility guidelines and we abbreviate that to WCAG. This is a W3C standard guidelines for accessibility. They've been really widely adopted by a lot of designers, engineers, companies, and they're wonderful. They outline different steps and different things to be considering.
For example, they break it down into four different categories: perceivable, operable, understandable, and robust. Each of these things has a lot of different checkpoints, but just as a brief example, when we think about “perceivable,” what assumptions are you making about your users basically? What are we assuming that they can perceive? Are we assuming they have perfect sight or sight at all? Are we assuming that they can hear? Thinking about how they're perceiving the product and then different design guidelines that go hand-in-hand with that.
“Operable,” similarly, is what are we assuming about the users, how they're actually operating with the product? Are we assuming they have really fine motor skills? That they can use a mouse, that they can use a keyboard? Are we assuming that they are able to use really quick reaction times, things like that?
“Understandable,” what is the general understandability of the product? Are you assuming really high language skills to be able to navigate? Or the ability to just remember really complex sequences, all kinds of things like that? Then, “robust” is a little bit different in that it talks about how is your product working with assistive technology? Like a screen reader, for example, which would be leveraged by someone who's blind to be able to listen to the product, listen to the phone, or the computer, whatever it may be, and get that audio output instead of the visual.
Poornima Vijayashanker: Nice.
Laura Allen: The WCAG is a great resource. I tend to think when I'm thinking about checklists and working with designers and whatnot, I break down into a few key groups as well. The first around keyboard and focus, just really taking a quick poll of—let's say you've got a site, how does it work with just the keyboard, no mouse whatsoever? It's a great thing for engineers and designers to be able to try that out themselves as well. Just try using the keyboard only and as you're navigating through, can you get to everything that you need to? Can you also see visual focus indication? If you don't see that and you're just tabbing through, you don't know what you can actually take action on. Have you thought about that in the design process, basically?
Then, I start to think about semantics. How do we actually make it more clear for screen reader users what the page is actually all about or what the app's all about? For example, do we have labels in place for buttons so that as you navigate with a screen reader, you don't just hear, "Button," or, "Unlabeled button," which is not helpful at all. Thinking about how do we just convey that experience and make sure that it's clear for a screen reader.
Then a third bucket, which I like to call think about in my audits, is just this idea of flexible interface. That can be anything from color contrast—so WCAG actually says we should have a minimum color contrast ratio of 4.5:1 for text against its background color. That's super helpful because for anyone, like me, with a low vision or just anyone who doesn't have the perfect 20/20 vision, it can be really hard to actually distinguish those colors, or a low contrast text, so that's a really helpful usability improvement for a lot of people.
In this same group of flexible UI, you think about things like how does this interface look with magnification at a 200% zoom level, for example? Or are we using just color, or just sound to convey information? Just color, one example there, is if you have an input field and you type an error and all of a sudden maybe just the text will appear red. In that case, people who can't distinguish color will miss that information, screen reader users, or braille readers will completely miss that information as well. Thinking about how do you go one step further and convey that and make sure there's also error messaging. You can still use the color red and all, that's fine but it can't be the only way that you're identifying that information.
I like to think through questions like that using the WCAG guidelines and other things that help there—like I know Vox Media has a really great checklist—and just get a sense of where's the current level? From that point, you may have a lot of different bugs, you may have different things that you want to be able to address, and the next step is naturally to work on, “How do we triage this? How do you prioritize?” I think one really helpful thing to do there is just to think about each of these bugs, what is the typical user impact? How critical is this? Would this bug stop somebody from being able to actually interact or take action on your site and your core purpose of your site or your app? I like to think about that, and help to prioritize, and just go from there.
Poornima Vijayashanker: Wonderful. We'll be also sure to include the resources you mentioned below in the show notes.
You've mentioned a number of things that happen during the audit. What happens after the audit?
Laura Allen: I think the next natural step, of course, is going through that triage and prioritization process. Then as you're solving these problems, as you're fixing bugs, continuing to go through and help to honestly integrate accessibility into each step of the process. I think that's the really critical step. One holistic audit is not going to take you all the way. We have to start bringing this into our development process and building it from the ground up. Then, honestly, getting out there and working with users, understanding what the feedback is. I think that's a really critical component to understanding how to improve.
Poornima Vijayashanker: I know in the next episode we're going to be going into a little bit more detail and boiling it down for viewers out there. Thank you so much today for joining us Laura.
Laura Allen: Thank you.
Poornima Vijayashanker: Now, Laura and I want to know: how does your company handle accessibility? Let us know in the comments below.
That's it for this week's episode. Be sure to subscribe to our YouTube channel to receive the next episode where we'll dive in a little bit deeper and share three key tips that you want to think about when designing for accessibility. Thanks so much 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.