Digital Accessibility As Strategy, Not Compliance

Jack Cunningham at UXDX Community: UX-Driven Code: Building with the User in Mind. Video: https://youtu.be/vREK0tM80y4

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

A high-stakes crossroads for accessibility

[00:00:07] Jack: Well, thank you. Today we're sitting at a really high-stakes crossroads when it comes to both access and strategy. Right now, 15% of the population is neglected and underserved, left feeling unsure, frustrated, yet determined, each and every time they want to use one of their devices. We as product and design professionals need to understand that the attempts to close the gap have largely been unsuccessful, because they're not tuned to thrive within an actual business environment. So that's what I want to talk about today.

[00:00:37] Being here today, you're going to learn some highly practical ways to address those feelings of your consumers. You're going to leave with an understanding of how to ingrain digital accessibility into your delivery culture. And most importantly, you're going to gain a few new skills that will help you combat those moments when you feel like the business pressures are encouraging you to just plow ahead without addressing accessibility at all. We want to focus on making access a strategic advantage.

[00:01:04] My name is Jack Cunningham, and I've always found great joy in being challenged by new perspectives. That's exactly what a focus on accessibility has always brought to me in my life and in my career, and I'm really thrilled to be able to share some of those experiences with everyone here today. I serve as a director of product management at Livefront. We're a digital product agency based here in Minneapolis, Minnesota, where we partner with organizations to define their digital strategies and then bring those to life by designing and building products and experiences that people absolutely love.

[00:01:36] Over the next few minutes, we're going to work our way through three things. Understanding what the accessibility landscape looks like and how it was shaped is really important, so we're going to start with a brief introduction, picking apart how we created this notion that we refer to as the checkbox mentality: viewing accessibility as a box to tick for compliance purposes. We're also going to talk a little bit about some of the dynamic and, frankly, threatening shifts that have been taking place over the last several months. That's going to launch us into number two, the discussion of strategy. When you're faced with pressures to move really fast, or even to justify why you should build something accessibly at all, how do you best navigate those scenarios in the context of an actual business? And last, we'll spend the majority of our time on examples you can take away today: what can you do to weave accessibility into how you deliver, so that it can really become a strategic advantage?

How the checkbox mentality was born

[00:02:36] Let's first get started with how we got here. When folks talk about accessibility, the conversation often stems from the Americans with Disabilities Act. In 1990, this was the law that brought about a great deal of physical access for so many people in the US. This is really what brought about ramps into buildings and braille on signs in public places. Life and business were taking place in the physical world, so Congress said, let's ensure that as many folks as possible can actually participate within it.

[00:03:11] Then, as the internet gained in popularity, an independent international organization introduced the Web Content Accessibility Guidelines. With the creation of this new space, albeit a digital one, they felt the need to assert what the ramps and accessibility accommodations of the internet ought to look like. This was guidance and suggestions for those who were interested, as more and more life was happening online. That said, the attention this grabbed was fairly niche at the time.

[00:03:41] Then a whole bunch of time passes and more and more stuff moves online. In 2018 the DOJ says, "All of you may have been a little confused about whether the ADA applies to you and to digital spaces. Well, here's our answer: it does. We won't say what that looks like or feels like, but maybe consider the Web Content Accessibility Guidelines a good guidepost for you."

[00:04:06] This sets off a whole flurry of action, some quite positive and some fairly questionable. Lawsuits begin to roll in, aimed at enforcing the ADA and trying to create better access for folks to consume and contribute to the web. However, at the same time, a cottage industry of sorts of cut-and-paste-style lawsuits begins to pop up. Those cut-and-paste suits bring about a huge burden for small and medium-sized businesses, because these firms were filing suits not for the sake of creating access, but oftentimes to win a quick buck and settle before actual change was brought about.

[00:04:48] But despite this really messy legal landscape, companies did begin to take notice, hiring folks who specialized in ensuring they could meet the requirements of the law and effectively de-risk their products and their businesses. This created the environment where the accessibility checklist would really be born. This risk mitigation tactic was not fully complete, but it was generally a net positive and created progress for the industry. It was an attempt to care about and deliver products that were accessible.

[00:05:20] At the same time as these risk mitigation tactics were taking hold, the big consulting firms were in the ears of our executives, coaching them and sharing a correlated insight they had recognized. They were noticing a correlation between companies investing in accessibility practices and an increase in revenue, often a great deal, at times a 2x increase. That combination of legal action and these correlated insights was really what cemented the deep desire for companies to draft and deploy an accessibility checklist.

[00:06:07] Finally, that brings us to a shift that's occurred just this year, with a federal push away from DEI and accessibility within the US. Large corporations are doubling back and heavily divesting from this work, embracing the fact that this administration has shared its lack of intention to take up ADA cases. Politics completely aside, this is really just a clear display that these firms were not able to make accessibility a strategic advantage. It was never more than that checklist, or a compliance consideration. It didn't actually permeate their delivery culture.

[00:06:43] While the checklist approach was not the be-all and end-all, these current trends are now putting those baseline efforts at risk. There's a real and present danger that we're about to take several leaps backward in terms of the accessibility progress that has been made. If you can't find ways to make accessibility core to your delivery culture, you'll only see a regression, because you're often measuring the wrong things.

Accept there's no single source of truth, and don't measure by ROI

[00:07:10] If that's where we've been, and we have this understanding of what the checkbox mentality is, we might now be in a better position to discuss how we actually do better. How can we build and design in a way that isn't threatened by having to justify why supporting a screen reader or a device orientation is a good business decision? How do you actually create experiences that support the widest possible audience and make it serve the business? It's quite the challenge.

[00:07:38] To do this, it starts with accepting that what you have to work with is far from complete. Earlier we discussed the Web Content Accessibility Guidelines, but the question naturally gets raised: should you really be applying those same web guidelines to something like a mobile app or connected TV, if that's what you're actually designing and building? The answer is almost certainly not always. Often, directly mapping those requirements from the web, or even just from modality to modality, is not even possible. We first need to accept that a single source of truth doesn't exist. There isn't a resource, nor a person, with all of the answers.

[00:08:18] Second, we need to be wary of tying discrete accessibility work to an ROI analysis. That can't be your measure. There are times when you can make assumptions and estimate the impact of increasing the accessibility within a key flow, maybe a checkout flow, and those numbers might follow a little more easily. However, this creates space for it to become your organization's habit to ask, "Well, how many of your users actually need this? Is the market big enough? Can we justify going forth without it right now, and coming back if people say they need this to be built accessibly?" Those are all the wrong questions.

[00:08:55] By accepting ROI as your measure of justification, you're turning a moral concern into a business concern, and that will keep you from reaping long-term benefits. It'll keep you from harnessing the indirect benefits, those that come from building things accessibly the first time. That's exactly where the magic is. That is the strategic opportunity: the indirect benefits.

Model, build awareness, seek perspective, reinforce

[00:09:21] If you can't easily define the requirements, and we can't tie it to the bottom line, it gets really difficult. Where do you go from here? What do you do? The answer is that you have to build a foundation that offers little nuggets of value along the way and is built into repeated actions. We must model accessibility, we must routinely make people aware of its impact, and we need to insert perspective and reinforcement as much as possible.

[00:09:49] Great in theory, but what do I mean? When you think about modeling accessibility, modeling builds a culture where you're thinking about it regularly, leading to more intuitive experiences being created in the very first place. We often see this starting, for us, with product designers. It involves regularly turning to peer products, just like we would for design inspiration in general, but doing so looking for what's good: modeling strong accessibility documentation, finding it in Figma communities, seeing organizations actually pulling it off within their products, and then imposing those same guardrails on the designs we're bringing to life, to bring about the best work possible.

[00:10:29] It's also about building awareness, and building awareness builds proactivity, to ensure you aren't signing up to rebuild or refactor things in the future. You're driving efficiencies. How do we catch things sooner with lightweight tools that allow us to build the right thing the first time? We often rely on things like the axe DevTools systems, integrating them into CI pipelines to highlight issues early on, so that we're inherently creating more beautifully written code in the first place.

[00:11:00] Then there's also the notion of perspective seeking. Perspective seeking brings about the discovery of new opportunities for your products, not just for those who rely on assistive tech, but for those who do not as well. And then comes reinforcement. Reinforcement brings about certainty and limits the unknowns, which completely erode roadmaps. For us, this often looks like including our standards for accessibility in the PR checklist, so every time code is reviewed, accessibility criteria are part of that conversation between engineers, creating cleaner, stronger and, again, more effective code.

[00:11:37] All of these items tied together are moral culture builders, carefully blanketed with things that have measurable, discrete value. In the near term, we're making stronger decisions, we're identifying new opportunities, and we're building solutions that are generally more scalable and effective from a codebase perspective. But very few people would look at those things and say those are accessibility initiatives. Rather, focusing on accessibility is a simple means to achieving those greater ends from a business perspective.

Example: accessibility-focused usability research

[00:12:08] What I want to do is look at a couple of examples. The first takes a step deeper into what we mean by elevating perspective. One way our team has been able to elevate perspective and uncover incremental value for organizations is through usability research. Many folks are aware that you can and should put your products in front of users often, and a lot more people are leaning into the tools that allow this to happen more seamlessly. The lesser-known fact is that there are a whole bunch of wonderful usability research and recruitment tools out there that allow you to put your product and your designs in the hands of people who actually rely on assistive technology, and gain insight really, really quickly.

[00:12:50] This past year I ran the Chipotle app through this process as part of a competitive analysis project we were doing, and I want to share some of the perspective wrapped up in it. We're going to look at the screen recording of an interview we did. What you're going to hear is a participant who was asked to complete the ordering flow, to order a burrito within the Chipotle app. This participant was completely blind and relied on the native screen reader functionality on her iPhone, called VoiceOver.

[00:13:20] What you're going to see in this video is a bunch of boxes jumping around the screen. That's showing the focus area for her. What's happening is the device is supposed to read out what is in that black box and allow her to orient herself in the app. When you watch this, you're not going to hear the announcements from the phone, but you will hear her reactions to navigating the experience. So I just want you to observe, watch the screen, and understand what she may have been experiencing going through this flow.

[00:13:48] Participant: My iOS just updated. I'm actually having trouble doing anything in the app now. It's not letting me sign in. It's not letting me order. It's just not... Okay, hold on. Nope. It's okay. Yeah, it's not. Okay, it's letting me... It's difficult to navigate because there are different parts of the app. Let's see if it's going to let me... Okay, it's going to let me... I don't want to. Okay. I usually don't sign in. I usually don't have an account.

[00:14:46] Jack: So what did you hear? What did you notice? Where did we lose her? The most obvious: she couldn't complete the task. The transaction fell apart, and despite really wanting to, she couldn't order her burrito. But if you take a look at some of the other key observations here, there's a lot of room for opportunity. In just a few short minutes, you find that opportunity quite quickly. If we look at this list, you do find value in these quick "here's what we should go invest our time in working on" items.

[00:15:13] But I think the bigger benefit is that you get to share this real human experience. You hear the frustration and experience of a real user, and that frustration is so easy to share. Perspective grows within stakeholders when you share this type of recording, because you're not only highlighting these opportunities and the ability to remove barriers, you're creating stories that are told in your users' words, not your own. You're not advocating for accessibility in the abstract. You're showing: here are these human pain points that present a lot of new opportunity for us to go solve for. I really believe that this accessibility-focused UXR is one of the quickest and easiest ways you could leave here today and actually start pushing the ball forward when it comes to accessibility.

Example: reinforcing with platform frameworks

[00:15:59] The second example I want to hit on in this four-part framework is reinforcement. How can we be really successful in reinforcing accessibility? One of the ways we've seen this come to life is by getting intimately familiar with the platforms you're building your product on top of. For example, the iOS and Android platforms offer up hundreds of first-party SDKs that you can lean into to deliver high-quality experiences, and this can actually be used as a strategic advantage when it comes to accessibility.

[00:16:35] Two of my favorite examples here are iOS's TipKit and App Intents, and today I want to focus on just the iOS framework TipKit. It's a UI framework with some great examples of how simply having awareness of it and integrating it into your product allows you to advance the accessible experience for users who rely on assistive tech just as much as for those who don't.

[00:17:00] If we return to the Chipotle app, we're going to walk through what their menu experience looks and feels like today. It functions a lot like this: you get a browse experience of all the toppings you might want to add to your burrito or your bowl. When you tap one of those items, a little tooltip pops up letting you know that you can swipe to customize how much of that ingredient you want in your bowl or burrito. However, similar to what you saw in that interview video, this was a custom-built component that didn't account for the screen reader, or even keyboard navigation. It isn't announced to the user, so when they make an interaction, they don't know it's there. They actually don't have the ability to customize what's going into their meal.

[00:17:40] Now on the flip side, on the right, you see a representation of TipKit, the UI framework that Apple puts out, and it tells a much different story. It allows you to produce that same experience, but far more effectively. You can see a view of that here. The question is, well, it looks pretty similar, so what's so wonderful about this? Out of the box, it handles things like Dynamic Type, automatically scaling up font sizes for folks who bump that up on their device. But that's not all; there are a whole lot of other benefits too. It provides screen reader support out of the box. It produces a common pattern that's really intuitive to users who rely on assistive tech, just as much as those who do not, because they're seeing it in other apps. And it requires far less development time to pull off.

[00:18:27] All these are incremental gains, and the beneficiaries are, again, those who rely on assistive tech. It's also a benefit to those who don't, and it's a huge benefit to you and your product team, because you don't have to have intimate knowledge of how to make all of those things happen. You're using strong patterns and reinforcement simply by knowing this is available and offered to you on the platform.

[00:18:52] Ultimately, our goal is to find where you can deploy these kinds of step functions, this framework, in small ways, and integrate it tightly into your weekly delivery motion, so that it's occurring throughout your entire development cycle and not happening as one large corporate initiative. A framework like this is critical to help you avoid just being at the baseline, that checkbox mentality, and to actually reap the indirect benefits of this work by making products accessible, with those bite-sized functions built into your life cycle. That way you can obtain the strategic benefit without losing momentum if something like the market changes, or there's a new administration taking power. Whether seas are rough or choppy or smooth, having these small, bite-sized bits permeating your delivery culture is really the unlock.

[00:19:44] What I wanted to highlight here is to encourage everyone to pull out their phone, scan a QR code and connect with me, because I want this to be a conversation. There's a focus here on finding the bite-sized chunks of work that you can actually build into your delivery cycle, because that's where the unrealized potential is. That's where this becomes a huge strategic advantage. If you connect with me, there are a bunch of resources I'd like to share with folks to help you create more accessible, sustainable and high-impact products. But ultimately, I'm not the all-knowing expert, because remember, there is not one. No one is. I really love connecting folks, and connecting folks to resources, so I think this is a big place to jump off and start further discussing how you find opportunities to build it into your weekly delivery motions. With that, I know we might have a little bit of time for some discussion, and I can share further examples if people have any questions they'd like to dive into.

Q&A

[00:20:48] Jack: Catherine, looks like you might be on mute.

[00:20:52] Catherine: There we go. You'd think I'd have learned at this stage. Thanks, Jack, that was really, really great. Thank you for sharing. From my perspective, it brought a broader conversation about accessibility. A big conversation at the moment is about business value, with companies dropping accessibility, so I loved how you brought the natural business value of accessibility back into the fold as just an obvious choice. That was really great. There were a few questions, not just one. There were a few questions around the tech stacks you use for accessibility. One in particular was: what platform did you use to record that session, the VoiceOver case study?

[00:21:35] Jack: Yeah, there are several that we lean on. For that one in particular, we recruited folks through userinterviews.com and then administered the test on Lookback. I also have a lot of admiration for the team over at Fable. They're a research recruitment platform purely focused on accessibility. They have a cool part to their business, too, where if you say, "Hey, I have a problem I want to solve and I don't necessarily know how to do it," they'll coach you through it. A lot of the recruiting platforms are doing a bit more of that coaching now. We've also been doing some on Maze, if you want to go with more of an unmoderated approach. So lots of really good tools out there, but those are some of the favorites right now.

[00:22:12] Catherine: And another follow-up was about accessibility tools in general. Is there anything you feel is a game changer outside of Maze or User Interviews?

[00:22:24] Jack: I highlighted it briefly, but finding ways to have the implementation checked for accessibility along the way is pretty big. When we're doing web projects, we're going to lean on axe DevTools and try to pull that into our CI pipeline a lot. The other bit is acknowledging, when it comes to designing our UI, whether we have similar checks happening, with touch target size definition, color contrast and device orientation, within the actual design. Our team has relied heavily on having a base project template that includes VoiceOver annotation, and includes the reminders to check all of your styles to make sure they meet compliance.

[00:23:15] So it's taking a look at the entire life cycle and asking, "Where can I have a nice, friendly bumper to continually remind us to focus on it?" And it's not just design who carries that torch. It's product, it's engineering, it's QA, so we find each of those little opportunities to bump into them. In the design files, relying on templates to remind you to define touch target sizes and so on. When it comes to QA, we're doing the same thing there. Or, as I mentioned, the PR checklist: when a PR is posted, you're just forcing a conversation. Ultimately, not everyone is going to have a complete understanding of what makes a unique design experience perfectly accessible. But if you're forcing the conversations and then relying on some of that research, it's a good, well-rounded, blanketed approach.

[00:24:08] Catherine: Amazing. This is more of a follow-on from that, and it will lead into another question: what are the types of questions or problems around accessibility that people come to you for help with? Is there a common one where you go, "Yeah, this is always what they need help with"?

[00:24:27] Jack: I think one of the big challenges comes with defining what is accessible. Generally, organizations say, "Hey, we want to be WCAG 2.2 AA compliant." You can go and read through what that means, but translating that to the platform you're building on gets really difficult. And oftentimes, if we ship a mobile app, there's also a website coming along as well, and you want comparable experiences. How do you approach that? So the question generally asked is, philosophically, is this accessible? Because we can't translate those requirements perfectly from platform to platform.

[00:25:06] One of the solves there, and it's a bit of gymnastics, is to get really familiar with the Web Content Accessibility Guidelines, the letter of the, quote-unquote, unofficial law, I will say. And then, on a mobile experience, what are Apple and Google putting out by way of assistive functions on the actual device? Where do these things map one to one, or where is one function on your iOS device mapping to five different criteria in the Web Content Accessibility Guidelines? So the question more substantially asked is how do we translate the Web Content Accessibility Guidelines to the platform we're building on, and the answer comes from being intimately familiar with the platform side of things.

[00:25:52] Catherine: Great. Another question is from a small company; it doesn't say the size, but they are the sole UX person on the team, and accessibility has fallen under her. Is there a size that would warrant having an accessibility expert, within the UX team or outside of it?

[00:26:18] Jack: It's a good question. I'm not sure I have a strongly held belief that when you hit a certain size of organization you should have someone very much focused on accessibility. Again, I think the way to be successful within a business environment is oftentimes to defer that when possible, and have it be a torch held by so many, and do regular audits with someone who is maybe that expert. The benefit of having that torch held by so many, and finding ways for it to be naturally rolled into what you're doing from a delivery standpoint, is that you're not having to say this is a company-wide corporate initiative. Because that's what oftentimes gets pulled into the really difficult business decisions: maybe times are tough and we need to find a way to scale back, and it's going to be the first thing that's cut, and it shouldn't be.

[00:27:08] Business pressures will encourage you not to focus on accessibility for so many reasons. So I actually think there's great value in trying to encourage each individual to hold a small piece of that pie together, because it's less susceptible to business drama. And as a sole individual from a UX standpoint, there are a bunch of great resources out there within the Figma community. CVS[?] has a really great mobile annotation library that you can go look up. Those are great ways to pull it in softly and naturally into the work you're already doing, to advocate for the pieces of the journey and experience that you have control and shape over.

[00:27:50] Catherine: It's phenomenal. I think that summarized your whole talk incredibly well, too: it should be naturally incorporated into the pieces rather than being forced. Jack, that was really lovely. Thank you. It was very clear. I loved the flow of it, and all the advice in the middle of it, as well as the case study. Thank you very much for that. For anyone who wants to share Jack's talk, you can do so. It'll be on our website, but it'll also be on LinkedIn, and it'll be available on the website after this for you to watch time and time again. So you can check back on those resources, and add Jack on LinkedIn as well, as he mentioned. Thanks, Jack. I'll talk to you again, and thank you very much.

[00:28:34] Jack: Appreciate you. Bye-bye.