Demystifying the challenges of adopting accessibility and inclusive design practices

Webinar Transcript:

Trevor Minton:

Hi, everyone. Welcome to Openfield’s latest webinar. Today we’re going to be talking about some of the perceived challenges of incorporating, and really about indoctrinating the ideas and thinking around inclusivity and accessibility in your UX design culture. I’m Trevor Minton. I’m VP of Product Experience at Openfield, and I’m joined today for our talk by Julee Peterson, Openfield’s Accessibility Lead. So Hi, Julee.

Julee Peterson:

Hey, Trevor. I’m really excited to be here today and chat about inclusive design and accessibility.

Trevor Minton:

That’s great. So am I. It’s going to be good. But, before we dive right into the presentation, we’ll give everyone some brief introductions. My role at Openfield is to ensure our product is the best it can be. That means leading and managing different facets of the team and our output. Openfield’s product is a combination of several things. It’s the performance of our team, the quality of our work, the collaborative relationships we build with our clients, and it’s creating successful outcomes for the teams we work with. Solving problems for all users, regardless of ability or any limitations is an ever-present common thread in these efforts. So with that, Julee, talk to us a little bit about your role, and your leadership of accessibility and inclusion at Openfield.

Julee Peterson:

Yeah, so I guess what it boils down to, as the accessibility lead, I am really here to make sure that the team is truly considering all users when they’re creating their design solutions. And I’m also working with our research and design leads to build relationships with groups that can help us in the ongoing effort to make our products more inclusive. And while accessibility is important to all product design, it’s absolutely critical to the work we do in ed tech, because institutions expect students to be able to use their products. It’s a requirement for procurement that these digital tools work for all students, and if the tool doesn’t support all students, educational institutions may be looking at lawsuits from the Department of Justice, or they may be even taking lawsuits out against companies that own these products. So ed tech companies would be looking at a loss of sales if their products can’t be shown to be compliant and accessible, and of course, there is significant brand perception to consider, if you don’t want your product to be considered somehow exclusionary.

Trevor Minton:

Perfect. Well, the point of our discussion today is to reveal some of the common challenges and concerns we’ve encountered from the product, UX, and engineering teams we work with. We’re going to group our talk into these three sections you see here. First, we’re going to just very quickly level set on the basic tenets, I guess I’d say, of accessible design. Second, we’re going to spend the majority of our time talking about how to ingrain this thinking into the culture of your teams and organizations. Third, we’ll talk about some of the tactics that are employed on a day-to-day basis, and we’ll also address some potential concerns we hear around additional cost. We’ll be spending about probably 30 minutes or so on those primary three topics, but we also welcome questions from our attendees, so with the time we have left after that first 30, we’ll answer any questions that come in to close out the webinar from there.

Trevor Minton:

Let’s get into it, and start by talking about clearing the first hurdle, which is simply understanding what accessibility is and what it means in UX and product. Julee, go ahead and get us started, and talk a bit about what it means to make a digital product accessible, and why that is important.

Julee Peterson:

Yeah, so accessibility simply means that at any given time, anyone can use your product, regardless of the many factors that are out there. I know that’s a pretty simple statement, right? But to build on that, and to talk about why accessibility is important, we start to realize just how broadly we should consider our users and their abilities. Consider the possibility that at any given time, up to 50% of your product’s users could be experiencing an impairment. Typically, we might first think about physical impairment, such as low vision or limited physical motion, but let’s talk specifically about what we mean when we say impairment, and there are different considerations at work here.

Julee Peterson:

An impairment can be situational. This could be as simple as users interacting with their device with their nondominant hand, which is extremely minor, but someone has to use a screen in the bright sunlight at some point in their life, where the contrast is washed out, making it hard to read for that specific use case. Then there are environmental situations, like these that come and go, and while they’re transient, they deserve consideration, especially if you have research that points to any reason why your user may find themselves in situations that have these limitations more often. Impairments can also be temporary, but these are still significant. This could be from an injury like a broken arm, where a cast is going to make digital interactions difficult for a few weeks or so. And of course, impairments can be permanent, affecting all of a person’s interactions with the world. People can experience a permanent impairment from birth, over time, or suddenly, and regardless, their experience with the physical and digital worlds are forever altered.

Julee Peterson:

If your product isn’t accessible, you’re obviously making things more difficult for users with impairments. Importantly, a lack of consideration of accessibility could be making the experience worse for users who don’t have impairments. This is, of course, just basic usability, right? Don’t make things difficult for any user. And there shouldn’t be any case where we think that one user gets the quick-and-easy path while another group will be okay with slow and challenging paths. Some good examples of assistive technology providing better experiences across the board are voice assistants. They allow speech-to-text transcription, or even the ability to launch and interact with apps by voice, with no physical input.

Julee Peterson:

Situational interfaces serve as a really good example of this thinking as well. Personally, I use Spotify every morning on my drive to work. It’s how I get through my somewhat long commute, and it has a simplified interface for those who are using it while driving. It minimizes, or attempts to minimize, distraction, and maximize the usability of only the core functions, like skip and pause. This is a really great example of a situational change in a user’s ability to focus on a device’s screen, and the designers chose to react to that by providing different options and interface elements.

Trevor Minton:

Well, with that little bit about the what and the why, briefly let’s talk about how we know if a digital product is accessible or not.

Julee Peterson:

Yeah. For one thing, determining accessibility is really a combination of many factors than a tightly defined set of checkboxes. You’re looking for varying degrees of accessible color contrast ratios, keyboard access, and screen reader friendliness. And details, like the amount of space around interactive elements, which make links or buttons easier to touch or click, are important to consider as part of your design solutions. So at first, you need to set a baseline, a baseline understanding of your product’s accessibility. Your design team should be able to set that baseline out of the gate, but if you don’t have a design team, there are a few things that you can do to start understanding how accessible your product really is.

Julee Peterson:

Specific to web-based products, you can download browser extensions. There’s a lot out there. A couple we’ve interacted with are AxE, Wave, and Google Lighthouse, and those allow you to run automated tests on your web-based applications. But we want to warn people that even the best free, automated testing tool out there is going to flag around 30% of accessibility issues. Another option would be to hire a third=party auditing organization. These companies have their own proprietary tools that they can hook you to your digital product, that can test for accessibility. These tools are usually a bit higher caliber than those free testing tools, so they’re going to come at a premium cost. And of course, you can always find yourself a kickass UX team to combine the best of all worlds. An expert team is going to leverage automated software-based testing, visual audits of the product, and conduct usability testing with people with disabilities. Synthesizing these three areas will reveal the best possible path forward.

Trevor Minton:

Well, great. Buy-in around inclusive design as part of the organizational culture is sometimes the elephant in the room for many teams. Understanding accessibility is one thing, but making it happen is another. We talk a lot here at Openfield about how accessibility should not be viewed as an add-on tactic. Rather, it must exist as a strategic, nonnegotiable element of the UX design process. That can sometimes sound intimidating to groups that are new to thinking about it, but if you don’t have design and engineering on board with that strategy, you’re going to be fighting an uphill battle as a product leader. These are significant concerns to overcome, and sometimes it starts with just this basic feeling that designers will be limited, or held back, when designing accessible interfaces. So, how do we think about that and address it?

Julee Peterson:

Yeah. I know personally, I can empathize with this statement, when it comes to designers, and I think you probably can too, Trevor, but if you can’t put yourself in a user’s shoes, it’s hard to break away from the traditional design methodologies that were baked into us throughout school and in the real world, but you really understand as soon as you see it. For me, it really hit home after attending a conference that was focused on making the web more accessible and inclusive. I had an awesome opportunity to run the UX process with a group of volunteers who have permanent impairments, and one of those volunteers was a young man who is blind, and uses a screen reader to navigate the web. He struggled a lot to get through what I thought was a simple flow for setting up an appointment, and it was heart-wrenching for me.

Julee Peterson:

I like to think of the web as a place that brings people together and makes information available to all, but when you see someone experience this much friction, it feels like we’re isolating them and reinforcing a sense of exclusivity. So it was then and there that I kind of started using the phrase that I don’t really care what it looks like. It should be obvious that if a blind user, or any user for that matter, can’t navigate a flow successfully, then a kickass visual interface probably isn’t enough to help them, but the aesthetic is important. Therefore, you know, we need to leverage good UI designers to create the best possible visual experience, but that UI is going to lean really heavily on the UX designers and the architects to ensure that inclusive and accessibility is baked into the product, regardless of the aesthetic.

Trevor Minton:

Exactly right, and that’s really getting us to the question of a team’s design culture, and how clearly they think about the people that will experience their decisions. What does a product leader need to be thinking about when it comes to changing their culture, so that their teams know how important accessibility is?

Julee Peterson:

I don’t think I can harp on this enough, but you need to start building empathy. If your company cannot empathize with the user or their customer, it’s going to be a hard sell for sure when it comes to changing the culture. My first suggestion would be to conduct real-world testing with people with disabilities, and invite members of your team to those sessions. It’s one thing to simulate impairments, and there’s actually a lot left to be desired, which we’ll get into a bit later, but watching someone with a disability reveal the usability issues of your product can be an unforgettable experience, and in the event that you can’t find users with impairments to usability test your products, we have somewhat of a backup plan. Get a meeting together. Find members of your team, and have them use their devices and the apps that they’re using every day, but take away their vision, or turn down their screen brightness, or just do some environmental testing in flat-out darker, crowded places. Put them into scenarios where they can start to build empathy for their users.

Julee Peterson:

We do this periodically here at Openfield, and there’s simply nothing like experiencing failure with a digital product that you already know how to use, or in our case, that we’ve actually created, to build empathy for users who experience the world entirely different than our team does. Once a designer feels their creation fail in that way, their empathy ratchets up exponentially, and it starts to become really easy to build a passion for this out of a desire to ensure that our products truly work for everyone.

Julee Peterson:

To build this into the culture, be sure to share what you learn across your organization, plain and simple, and not just with product, UX, or engineering. Find a way to get accessibility in front of your marketing team, your directors, the C-suite, because ultimately, these people are the ones that are going to call you into their office demanding to know why the product you built is not compliant or accessible. Caring about inclusivity is automatic if it’s authentic, and it’s a belief at every level of the company.

Trevor Minton:

That’s exactly right. It has to be reinforced and routinized into the culture. Along those lines, something else you should probably be asking is, “How do I make sure my team thinks about accessibility from the very start, not just at the end or maybe late in the game, as kind of something that they would consider a fix or an add-on?”

Julee Peterson:

Yeah, so let’s start at the beginning, right? That’s the design and the prototyping phase. Personally, I’ve found that prototyping interfaces with tools like Axure or Webflow is the most successful way to start achieving this. These tools actually allow for a more robust form of prototyping and testing than using some of the built-in prototyping tools in some of our design programs. This form of prototyping allows a designer to start with components, so they don’t have to worry so much about the aesthetic. When I’m doing this, I find that I can really focus on the interactions, and the user flows, and hone in on things like how a keyboard user might tab through the system, or what I would want a blind user to hear when they’re reaching specific components or the pages in the flow. These prototypes can support empathy-building with designers, and maybe more importantly, they can be tested with assistive technology, to validate the approach. The prototype elements are accurate to how they will actually function in the real product.

Julee Peterson:

Then, when it comes to the final user interface, so the final designs, there’s also a lot of great tools for the designers who are using these design products, so Sketch and Figma specifically both have plugins that allow designers to check color contrast ratios of their design while they’re actually doing their work. The great news is that it really becomes second nature over time, with practice and experience, and though these plugins are great, I can honestly say that we use these types of plugins less frequently day after day, and this is most likely due to the fact that we have been scrutinizing each other’s designs for contrast over the last couple of years.

Trevor Minton:

We can spot it across the room, most times.

Julee Peterson:

Then we get to the final piece of all of this, and it’s obviously the specs and the final designs are the visual side, but when it comes to handoff, we need to make sure that we’re documenting all of the user experience. So another part of our job is when delivering the work, we need to start annotating the UX acceptance criteria. Depending on your team, you may be documenting AC a bit differently, but what we’re used to using is something called a PRD with our current clients. A PRD is a product requirement document, so this is the place to communicate user needs and expectations to the engineering team. This is our one source of truth, and where we should be outlining things like what the user should hear if they’re using a screen reader, or what tab order should be happening on individualized flows.

Trevor Minton:

Yeah, and that’s the perfect segue from design, research, and testing to kind of a hurdle we’ve seen in the past with engineering teams. You know, the engineering team and development has to be integrated into this product culture of believing in the importance of inclusivity, so this situation, where the dev team maybe doesn’t know how, yet, to build accessible designs, or even worse than saying they don’t know how. They’re actually saying they don’t think it can be done. I don’t know. How have we helped teams navigate a concern like that in the past?

Julee Peterson:

Yeah. Honestly, life is tough for dev teams. For a short time early in my career, I did quite a bit of frontend development work, so I have a light understanding of the pressures that engineering teams already face, especially when it comes to committing to work at the beginning of a sprint and then putting out all the fires that happen in the live product, so accessibility considerations can potentially make a job even harder for them. But, they have to be on board with this, and really, it’s likely they know more about how to do this than they realize. Still, as a product leader, you have to give them what they need to succeed. You have to be there to support them.

Julee Peterson:

To that end, if your dev team is lacking in understanding, there’s numerous resources out there for them to learn how to make sure their code is accessible. A big thing that they should know, and where I usually come from, is creating standard semantic HTML. Accessibility is already built into those pieces, and those semantic elements, so there’s no extra work for them, and relying on standards doesn’t have to mean cookie-cutter output. If your design team is pushing for custom looks, start with a standard component, and customize that rather than starting from scratch. And if you need to take customization further than that, and you do have to start from scratch, there are specific methods and techniques, such as Aria label attributes, which may require some additional training and resources to solve. So if training is necessary, I say go for it. The entire team becomes better when just one groups amps up their knowledge in a specific area like this.

Julee Peterson:

And ultimately, we need to integrate engineering throughout the product design process in order to avoid these types of moments of surprise, and work together to create a clear definition of what accessibility needs to mean for the product to succeed. Of course, integrating product, UX, and engineering throughout this has obvious benefits to the outcome, beyond accessibility.

Trevor Minton:

Yeah, absolutely. A minute ago, you mentioned the potential need for additional training and learning. What kind of resources are available?

Julee Peterson:

Oh, there’s so many. There’s so many out there. Personally, I would recommend webinars from some of your favorite organizations or accessibility thought leaders. I’ve taken quite a few of my lunches in front of my computer learning something new about accessibility and usability. There’s a lot of people talking about inclusive design right now, and you should hear what they have to say, and contribute to that conversation. Conferences are also a great way to pack in a lot of learning in short periods of time, and like I mentioned earlier, this year I went to a great conference called AccessU, and again, that conference focuses on making the web a more inclusive and accessible place.

Julee Peterson:

A lot of larger companies, like Microsoft, Apple, and Google have created their own how-to guides, and toolkits, and design languages that we can start to learn from and implement into our own practices. I’ve even come across organizations creating their own heuristics for digital products, built specifically with accessibility in mind, in hopes that we can create an awesome UX for all users. We have quite a large list. We didn’t want to put it on a slide, because who wants to read a URL? We’ll send those out to whoever has joined the webinar, whoever accesses the webinar.

Trevor Minton:

Very good. All right, well let’s head into the final part of our discussion, and talk about tactics and the bottom line. Let’s say you fully understand the importance of inclusivity, your teams have embraced it, and probably your organizational culture is even starting to support it from the ground up. So now as a product leader, you have to make that happen all the time for every single release, and it’s at this point that we hear legitimate concerns from our clients about how to know what problems to fix, how to think through the prioritization of those problems, and how to budget for what is suddenly a new normal. When some groups take the first steps, they can experience this paralyzing moment. They come to us, maybe after running, say, an in-browser accessibility checker, and literally, they might find hundreds of errors being flagged. Now they’re looking at this whole host of problems that they didn’t even know they had previously, and some of them are legitimately freaked out at that point. So, yeah, now what?

Julee Peterson:

Well, don’t freak out would be my first recommendation. It’s going to be okay. Those audits and tools can be overwhelming, but you need to prioritize, and the easiest way to prioritize is to start outlining the fundamental needs of your users when it comes to your product. First, outline the major user journeys for your product. For instance, if your users have to sign into your tool or your application, and you discover that some users can’t do that, start there, because I’ll tell you, nothing else matters at that point. We know some teams and people rely really heavily on numbers and data when it comes to understanding priorities, and we have created an algorithm, with a spreadsheet, to help teams sort out priorities with some numbers to guide them. This tool is essentially designed to help stakeholders understand the severity and impact of usability issues, and this algorithm isn’t just focused on accessibility, but the entire usability of your product, with respect to specific user journeys. You can learn more about that on our site, and download the sheet to use as a guidepost to help you sort out what areas need the most attention.

Trevor Minton:

Now, we know that many teams are dealing with products midstream, at any number of different points of their release cycles, but what about a team that is tasked with building a brand-new product from scratch? How do they go about ensuring that their process is focused on accessibility from day one?

Julee Peterson:

I would start off with partnering with a UX firm who practices inclusive design and understands accessibility, and do your homework. Look at their work. Check out their case studies. Check out the products that they’ve worked on. A great UX company will have user testing and research baked into their process, and the same will be said about accessibility. There are firms out there that are not thinking about this yet, which is shocking, because we literally think about it all day, every day when we’re in the office, maybe sometimes even outside of the office, so make sure to figure out that your potential partner knows what they’re doing.

Julee Peterson:

And if it’s still unclear, ask them what their process is. If they don’t have an answer for you, or you sense any sort of double-talk, that might be a red flag. We’ve had clients coming to us after threats of lawsuits, because the firm they worked with in the past didn’t think about accessibility, and really, my goal here at Openfield is to stop talking about accessibility as like this unique entity within the UX process, because to me, it’s just a subset of usability. And while I say that, we also need to keep in mind that accessible doesn’t necessarily equal usable. Your team might think they checked all their boxes for accessibility, but when a user interacts via assistive technology, and they still can’t use your product, because the basic usability is poor, you’ve still failed.

Julee Peterson:

So, without user testing upstream, so before development… When we talk about upstream, do testing while you’re in the design and iteration process. Use those robust tools to make sure you’re getting it in front of all user types. And then also downstream. Once you launch a product, once you have a release, get it in front of users. If you’re beta testing, that’s a perfect opportunity to run it through whatever sort of flows or testing you need to. You really won’t know if your users can actually use the product unless you are testing with them.

Trevor Minton:

Right. So really, we’re talking about an ongoing, almost evolutionary process here, so along the way, what do we think about the reality of living with a lack of perfection while you’re doing all of this work to improve?

Julee Peterson:

Well, I can honestly say that nothing is ever really perfect, is it, Trevor? But there are some things that you can do to start showing that you care, and you are thinking about this. Tell your users what you’re doing. Add an accessibility statement to your site, and if you don’t have one, work with your teams to create one. It’s a team effort, and you need to get everybody on board, so maybe that’s your first step, getting every facet of the team together to talk about what accessibility means within your organization, or specific to your product.

Julee Peterson:

There’s also some tools out there that can help you do this, so you’re not alone. There are all these companies that are trying to make the web a more inclusive place, have some sort of tool to help you build these statements. Let your users know you care, and that your product may have issues, but you’re working on fixing them. Also, ask for their help. If your customers experience usability and accessibility challenges, make it easy for them to let you know what they found. Add a feedback loop to your site or your product. Put it directly in the app. Request that kind of feedback, because ultimately, your users are going to determine and help you shape your product, so be comfortable with that fact, that it will never be perfect, because all we can ever do is keep trying and keep testing. Technology will always advance, so we constantly need to make sure that our products can stay up to date and function under the changing landscape, and in true agile fashion, nothing is ever really done. You need to keep updating, keep learning, and keep improving, or you’ll fall behind.

Trevor Minton:

Well, let’s wrap up with a bit about the bottom line. When you hear us talk about accessibility, and along those lines, we’re also talking about the need for research, and testing, and improving upon our existing tools and skills, building up culture from within, all of this, it’s really no surprise that we’re often asked if accessibility is worth it, because of the expectation of increased costs.

Julee Peterson:

And I think it’s logical to consider the additional cost of adding new and disciplined thinking, and even testing to your workflow, but it’s going to cost a lot more to retrofit accessible design and functions than it does to indoctrinate this as part of your team’s culture, and part of your practice, and part of your process, so when accessibility and inclusion are part of your definition of done, and the product can’t be considered a success otherwise, the value’s going to far outweigh any additional time spent in the design and testing phases. And as we said earlier, many of the tenets of accessible design become natural for UX designers, and don’t actually add any extra layer of effort, usually, in a short amount of time.

Trevor Minton:

Exactly right. Well, that’s great. Thank you, everyone who joined our chat today, for that first almost 30 minutes, and we’ll wrap things up from here, but with a quick summary, we know that UX and product teams face plenty of challenges when building products, across the board. It can be intimidating, therefore, to start thinking about how to include people who may interact with our work in ways we had not previously considered, but in our experience, these concerns can be alleviated fairly easily, and in a pretty short amount of time, they can prove to be not much of a quote-unquote “extra add-on” as it becomes an ingrained part of the culture of that team and the organization.

Trevor Minton:

At this point, hopefully we’ve answered some of the key kind of basic concerns that many teams have, and have brought to us over the years, and we’d like to take a few moments to answer a few questions that have come in from our audience. Julee, I’m going to dive right into this first one here, that is actually pretty exciting to talk about, just because of the recency with which we’ve been discussing it here. I’ll just read the question verbatim here. What do we think about some of the high-profile legal issues that have come to light around digital accessibility, especially something like Domino’s fighting all the way to the Supreme Court to avoid making their apps accessible?

Julee Peterson:

Domino’s, yeah. This case is really interesting, and we’re watching it, I would say, pretty closely. Most interesting to us is how differently it’s being reported. On one hand, it really does sound at first like Domino’s doesn’t want to make their digital products work for disabled users, choosing to spend money on a legal battle instead of trying to make it accessible and inclusive. But on the other hand, they’re trying to challenge the open-ended nature of current regulations, and it seems like they’re arguing for more guidelines, that would actually define what it is, and what accessibility means in the digital world, the same as how we understand accessibility in the physical world, right? So ramps, sidewalks with roll-ups, and things like that. This one could potentially have significant implications for what we do, and we’re going to follow it really closely moving forward.

Trevor Minton:

Yeah, definitely. I think it’s a good opportunity to pay attention to how that proceeds and eventually wraps up, and just kind of keep putting our perspective on it. I think all of us are going to learn a lot from that. Let’s see. We’ve got another question here, about the empathy sessions we discussed.

Julee Peterson:

Ah, yes.

Trevor Minton:

When you talked about conducting empathy sessions, I wonder if that is good enough when you’re not really the one who experiences the world in that way. You’re instead knowingly experiencing something brand-new and freshly limiting, so does that maybe kind of surprise, I guess is what they’re saying, does that affect what you might take away from a session like that?

Julee Peterson:

Yeah, I think that’s the correct thought to have, right? We’re not our users, and we have to test with our users. This is true regardless of whether or not we’re talking about accessibility for impaired users or just how our product works. Empathy sessions are not actually enough on their own, but they are good experiences for designers, and we’ve found that to be true quite often, because even though we’re not the user, we get a good sense, or feel, of what limited accessibility means to typical design decisions and interaction patterns.

Trevor Minton:

Great. Yeah, no, that makes sense. We had one more question queued up here, so you talked some about engineering teams, and how engineering has to make these things UX and product creates into accessible, inclusive products. What part of that is the UX team’s responsibility, is really kind of the core question here. They’re saying it sounds like it’s all in the development team.

Julee Peterson:

Yeah. I think at its core, it’s always going to be a team effort, and the tools specifically that we’re using allow us to test and check as we go, so we also need regular points of communication with engineering, so that we can keep them aware of all of our decisions. Accessibility is obviously included in that. Acceptance criteria and annotation document these decisions and directions, and ensure that the product team is aware of these decisions as well, and they’re on board, and we can work in a collaborative effort, to continuously make them better. And eventually, this comes full circle with QA testing before release, and ideally, once more with post-release testing. And after that, the solutions have been built so we just constantly need to test and make sure… It all comes down to usability. We just need to make sure we keep improving the usability of our product and keep accessibility in mind as we’re doing it.

Trevor Minton:

Yeah, absolutely. I think it’s part of that thought of accessibility isn’t an extra. It is part of the criteria of success for what we all build together.

Julee Peterson:

Mm-hmm (affirmative).

Trevor Minton:

Okay. Well, thank you to the three of you that submitted those questions as we went through the presentation. That wraps things up for us. We will be making a recording of this webinar available on our site, and all attendees will receive an email with a link to that page. On that page, not only will you be able to access the screen cast and audio recording of the talk. We’ll also include the additional material and links that we referenced along the way. With that, we are wrapped up, so thank you everyone for joining us.

Julee Peterson:

Thanks, everyone.