Accessibility via the path of least resistance

Dianne Tennent at UXDX Community: Streamlining Service and Accessibility Design for Product Exploration and Workflow Optimization in Enterprises. Video: https://youtu.be/Sx5wGavzg38

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.

Why accessibility

[00:00:00] Kia ora, I'm Dianne. I'm from Aotearoa New Zealand. It's lovely to be here. And yes, like you said, I'm a software developer for Optimal Workshop. I really liked that intro, the graphic of these kind of isolated projects and then this kind of product thing, moving from those silos into that cohesive system kind of approach, is very much the theme of my talk. So I'm going to be talking about accessibility, building accessible digital experiences, and I'm going to pitch this idea of the path of least resistance as an approach. So here we go.

[00:00:46] Before we talk about accessibility, it's worth looking at that question: why accessibility? I think in this day and age most everyone would agree that building accessible digital experiences is really important, and it's kind of a given for a lot of us, but I think it's worth mentioning actually these are the reasons why. If we compare it to public life, we don't build stores or train stations that are not accessible to people in wheelchairs, so why do we build the internet that way? There is a large percentage of the population that would really benefit from digital experiences that are built with the accessibility criteria in mind.

[00:01:32] And while mandates might not be here yet, they are coming, particularly in government organizations. So any kind of B2B, enterprise, that wants to sell to government is going to need to meet those criteria. So we're kind of shifting from this kind of goodwill, yeah, this is what we think is the right thing to do, into this kind of phase of, actually we just have to do it.

[00:02:01] And also our customers are actually asking for it. So on the right hand side there you'll see just some snippets of conversations that have happened over the last few years between some pretty key customers there, who are contacting us and asking us, what's your approach to accessibility? Because we need to know, because we need to make a decision about whether we buy a product. So that's the why for talking about accessibility. But from my perspective as a software developer, I'm much more interested in the how.

Retrofitting a sixteen-year-old product

[00:02:39] So to put a bit of context, hopefully everyone knows that the ideal scenario for accessibility is that we're starting from scratch and we are designing for accessibility from the beginning, we are building with accessibility in mind from the ground up. That's obviously best practice. But in reality, like Katherine was saying, we're a 16-year-old product that was not designed or developed with accessibility in mind from the get-go. So we are in this position where we are needing to retrofit our existing product, which is quite the behemoth, you might say. And so that's no small feat. And I think a lot of people are in this scenario, because of the shift in the status of accessibility from being something that's a nice to have to something that's actually essential in recent years.

[00:03:43] And looking at our accessibility strategy, I did a bit of digging into the archives and had a look at our journey, where it started and how we got to where we are. So, a little bit of a timeline. 2018 is where things started to kick off with an accessibility club, then spreading those kind of things companywide. We had a bit of a pivot in 2020, we thought let's just do what customers ask us to do rather than being that sort of proactive. Then we get in 2021 a key customer contract that actually has a clause in it for accessibility. And 2022 we completed a successful accessibility project for part of the app, which I'll talk to later.

[00:04:30] I've just put the company logos. You'll see the bottom left, we've got the old logo, and then 2020 is when we updated our branding. So it kind of gives you a bit of a sense of what can be achieved in that timeline, and maybe compared to how accessibility has fared over that same kind of time period.

Where we are now

[00:04:57] So, smash cut, where are we now? You'll also have to forgive, I being a software developer and not a designer, my slides are going to be much more basic than the next two presentations that you'll be treated to, so please forgive that. But a bit of a snapshot of where we are now. Yes, we have completed one successful accessibility project for part of our app with one team, and that was a really, really good thing to achieve. We do have automated accessibility testing in our code base, big tick, and this is going to be a really core part of what I'm going to be talking about for the rest of the presentation. But we've still got large parts of our application that are not accessible, unfortunately.

[00:05:43] And then in terms of our product roadmap, we've had a bit of a shift recently, from a goal that's kind of explicit, something that we're working towards, shifted into this kind of, this is just the way that we do things now. And so when I hear something like that, my big question is, well, if it's the way we do things, so how is that going to happen? How are we going to make it part of the way that we do things?

[00:06:08] So my beautiful graphic there is demonstrating this idea of, maybe in the past sort of five years we've had these different kind of siloed approaches to accessibility. Things are happening in the research space, things are happening, there's one team working on a project, there's people doing presentations, there's a club. But what I'm going to suggest that we move towards is a more cohesive system that works as a system, is an approach to the way that we work that is kind of integrated and is hopefully self-sustaining into the future.

Why the old approaches did not work

[00:06:51] So to get to this point, I did a bit of looking back to, how did this system fail in the last sort of five years, and what can we learn from it? So this approach of deploying one, we call them product squads, a cross-functional team, to a project for a part of the app: the idea was that this team would massively upskill and do this project, and then we'd move over to another team with another project and that team would upskill, etc. And that was great for that one team, and that team became really, really skilled in that discipline. But unfortunately, due to our product roadmap changing and priorities changing, the rest of that cycle didn't end up carrying through. So we've got a few people who really know their stuff, and then we've got the rest of the team that still have a lot to learn there.

[00:08:00] So in that process, the second team that we put on the second project, part of the approach was to upgrade the tech and also make it accessible. So in our team we thought, okay, well we'll do the upgrade and then we will look at accessibility. So, did the upgrade, big tick, and then of course, because we're agile, because we are constantly refining our product priorities, the accessibility portion got dropped off. So this kind of approach of, well, we'll do the bulk of it first and then we'll go back and make it accessible, that did not work. And hopefully it's a good reminder that it's not a good approach.

[00:08:48] The next one there, the accessibility champion. So we love the accessibility champion, we need the accessibility champion, but an accessibility champion alone is not going to magically transform your 15-year-old monolith into an accessible product. So I think it's a mistake to say, oh, this one person over here, they've got accessibility covered, I don't need to worry about it, they'll get it sorted. So that's kind of, we have a few passionate people in the organization, but it takes a little bit more than that to actually really make headway.

[00:09:30] Online courses, great, encourage your people to upskill, here's a bunch of learning resources that you can use to learn about accessibility. But the unfortunate reality is that getting that buy-in and getting people to devote large amounts of time to that really kind of specialized learning is not something that happens all that often. And I think people have different paths, different focus areas, different things they need to learn. I mean, developers have a lot of stuff that they need to upskill in all the time just from a technical perspective. So while these are good options, they're not a silver bullet.

[00:10:15] And goodwill. I think we all want to do the right thing, and we can talk about doing the right thing, but as much as we want to build things in an accessible way, that's not going to create a self-sustaining system for making accessibility part of the way that we do things, like we're kind of wanting to do. All right, I've got a cat meowing at me in the background and I'm just going to ignore that for now.

The barriers

[00:10:47] So what were the barriers? Why did these things not work? And I've touched on this a little bit, but time is a factor. Like I was saying, developers have a whole bunch of stuff that they do need to upskill in above and beyond or outside of accessibility. So being able to really set aside the time for upskilling is really quite a challenge.

[00:11:11] And I've put WCAG there, the Web Content Accessibility Guidelines. So if anyone has kind of dipped into that core resource, it is like an important, really authoritative resource for defining the criteria, really high level, really broad, really exhaustive criteria for how to make digital experiences accessible. However, because it is so high level, because it is so exhaustive, because it applies to so many different scenarios, it's an absolute tome of a resource. And so anyone who is going to be going, okay, well, how do we make this accessible, let's have a look, are going to be immediately overwhelmed by just the sheer amount of information there. So in a way that itself can be a barrier. Trying to find resources that are really practical and applicable to your specific situation can be really, really tricky.

[00:12:24] Priorities. So we're always trying to kind of go faster, right? We want to get things done as soon as we can, we want to deliver as soon as we can. And so there are a number of ways that we tend to cut corners, and accessibility is often one of them. Like I was saying in that previous situation, oh, we'll upgrade the tech first and we'll do the accessibility afterwards. So competing priorities becomes a real barrier to becoming accessible.

[00:13:01] Expertise. So we don't have experts in our team. We don't have the luxury of having an accessibility advisor to kind of come in and verify that what we're doing meets the criteria, or someone that can do an audit. So that in itself is a barrier. We have a lot of good people with goodwill, with good passion, who know a lot, but we don't have that kind of definitive, yes, this is accessible, or no, it's not.

[00:13:30] And lastly, technical risk. So making changes to a huge monolith at a technical level is very risky, and in particular when it comes to component libraries. So I'll talk a little bit about that later, but just that idea of making a small adjustment to a component means that there's obviously instances of that component across huge parts of the app. And particularly when it comes to styling, the risk of styling regression is quite real, and the ability to mitigate that is quite difficult when you have a complex application with a lot of different states of the UI. So the QA around that can be quite resource heavy. And that's kind of another barrier, but I'll talk a little bit about that soon.

The path of least resistance

[00:14:33] So given we've got all of these barriers in place, all of these reasons why we want to put accessibility on the back burner, worry about it later, someone else can do it, how do we move forward? So I'm pitching you this idea of the path of least resistance, and you can think of the rocks in the picture there as the barriers, and what we're going to do is just cruise through them and make some headway despite those barriers. So come along for the ride.

[00:15:08] Looking at the system as a whole, one part of the system that is essential to make things work is, we need that C-level directive. So without kind of your own internal mandate of, this is the way that we do things, from upper management, it's going to be really tricky to get buy-in from your team and from your developers. So if you can get that from management, if you can get them to articulate the why, particularly from a business strategy perspective, not from a "this is the right thing to do" perspective, then you can really get some buy-in and set those expectations for future development.

[00:15:49] So, automation. Having automated testing is a really huge part of this picture, this system, and outsourcing the bulk of the work to automated tools. And I will talk a little bit more about that. But it's not the end of the story. Automated testing doesn't solve the whole problem, but it's really important to acknowledge that it does solve a lot of the problem.

[00:16:22] So, to show you an example, a resource. This is the testing toolkit. There are free tiers, there are paid tiers, but we have the free tier which is just within our system that we can use to scan parts of the app, and it will spit out some results, and it'll say, these are the accessibility violations that you have. So it's a really big part of our strategy of increasing the amount of testing coverage that we have from an accessibility perspective across the app.

Not reinventing the wheel

[00:17:04] So, not reinventing the wheel, using existing resources. So rather than diving into WCAG and trying to figure it out for yourself, Deque University is a really useful resource, and they have checklists that are really practical, applicable to the work that you're doing from the day to day. So here is one of them, this is a developer's guide, and you'll see it's really specific. So, hey, check that your lists are marked up using real HTML list elements. Make sure the reading and navigation order is logical and intuitive. But again, this is quite a huge page with a lot, a lot, a lot of criteria, and a lot of these are not going to be relevant to the app that you're working on.

[00:17:50] So what we did was, and I'll point your attention to this right hand column which says testing. So some of these things can be tested by automated tools, great, some of them can't. So some of them actually need a human being to look at the page, test it out manually, to make sure that it's doing what it's supposed to be doing. So what we did was pull elements from this checklist that we know are relevant to our app and isolate the things that require manual testing from the things that can be tested with automated tools.

[00:18:28] And so that then allowed us to focus on what I call the human quotient. So focusing our energies on what can only be tested by designers and developers, and not worrying so much about those things that can be tested by automated tools.

[00:18:46] And so this is the checklist that we kind of came up with for our particular use case. And you'll see those first three things, I've called these universal checks. So in every situation and every feature that we're working on and every part of the app, we need to check for these three things. Three things are quite easy to check for, and the more that we do it, the more it becomes embedded in the way that we work. So reading and navigation order, zoom to 200%, and visual current keyboard focus. Those are things that automated tools can't check and that will always be relevant.

[00:19:20] Then the ones below there are more sort of context dependent checks, so depending on what feature you're building may or may not be relevant. But this list was just a really manageable subset of things that, when we were going, okay, we need to build this thing in an accessible way, what should we be thinking about? Boom, boom, boom, looking through each thing, is it relevant, how are we going to make sure that it's accessible as a team? And so the more that we did this, the better that we got at it, and the less tedious it was, you can imagine.

Accessibility debt, the easy way

[00:19:54] So, okay, another part of the system is talking about debt. So making a distinction between existing debt and new debt. We talk about technical debt, but let's also talk about accessibility debt, and paying it off, yay, we really want to do that, and acknowledging the reality of the debt that we have accrued up until now. Combined with, if it ain't broke don't fix it. So there are different ways to make accessibility improvements. Let's do the easiest way, let's actually just do the minimum, and I'll show what that kind of means.

[00:20:33] And this relates to that component library issue where there's that large amount of technical risk, and we don't want to risk styling regressions and things like that. So this was something that I presented to the development team, to say, let's fight debt in the easiest way possible. So before we begin, do some test-driven development, where you're saying, before I start any development in this component I'm going to put in an assertion that says I expect there to be no accessibility violations.

[00:21:04] If there are accessibility violations, can you fix them in the main part of the app, because that's the easiest way to do it? If you can, great, do that. If you have to make a change to the component library, which is that really technically risky thing, ask yourself the question, is this going to change the styling? Because that's where that big risk is. It might not. There are a lot of cases actually where the fix won't change the styling, so that's a really quick win there.

[00:21:31] And so a few kind of questions to ask yourself, and these kind of green stars saying, hey, in this case it's going to be easy, in this case it's actually going to be really easy, here's a really easy way of doing it. And that's that path of least resistance. And then some kind of scenarios for where things are a little bit more on the complicated side.

Sharing the knowledge, and the system

[00:21:54] So you can kind of see within that approach you've got that within-team collaboration, where we've got this checklist, we're discussing it as a team, we're building our knowledge as a team and building our awareness of what accessibility things we need to take into account, and making sure that's a shared discussion. We're not outsourcing that to one individual, we're doing that as a team.

[00:22:19] And then the other piece to the puzzle is this kind of cross-team knowledge distribution. So we've got a few passionate people, and lots of people know some things, so we created a fortnightly forum where people can come and ask questions, share insights, and it's this kind of really informal, kind of even like looking at the app and learning together. Just aware of the time, so I'm going to hurry through.

[00:22:45] So there's our beautiful system, creating this different type of waterfall than you might be used to be hearing about. So developers are motivated to avoid failing tests, which means they need to consult with designers about these decisions, which means that the designers will hopefully start to think more about these things to unblock developers, which means that product owners are going to be involved in making these decisions, factoring accessibility into the picture.

[00:23:16] And that's my idea of the path of least resistance. And I hope that it's helped you to maybe think of accessibility as less of a too-hard-basket kind of thing, and something that can become part of the way that you work. That's me, I did it. Thank you so much for listening.

Q&A

[00:23:36] Host: Wow, that was fantastic. There's so many questions and I have so many questions. The part for me was the practical end, on the overall theme, path of least resistance. I liked the buy-in from the C-suite, and I think it was almost self-explanatory at the end, because you talked a lot about trying to get buy-in first. But when you mentioned tech debt and equated it to accessibility debt, that's millions and billions companies spend on that. So that statement alone should be enough for people to have a wake-up call on why accessibility, and not having accessibility debt, is just so important. So thank you for that, that was really nicely laid out, and that answered three questions around that topic, I feel. But if anyone has any follow-ups, they can do it afterwards.

[00:24:24] Host: My other thoughts were on the leverage automation you talked about. You talked about outsourcing the bulk of the work and then focusing on the manual piece. What tool were you talking about when you mentioned Deque University? Is it available on their site, or was there another app that people could use to look at automations and how to fix it?

[00:24:47] Dianne: Yes, so the tool that we use, the testing library, is axe, and it's kind of a core API for doing that kind of scanning. And that kind of comes in a lot of different forms, so depending on the platform that you're using there'll be a different form of that library that you use. So we have some React and we use the Jest testing library, so we use something called jest-axe, which is based on that kind of core API. So as a technical team you'll be able to find a lot of free libraries that you can embed into your product based on that core axe API.

[00:25:29] Host: Yeah, amazing. And just another quick question here, sorry, there's a few I want to get to them. Who was the accessibility champion within your team?

[00:25:42] Dianne: So it was another software developer. His name is [?].

[00:25:49] Host: A designer, interesting.

[00:25:51] Dianne: Yeah, yeah, yeah.

[00:25:54] Host: Sorry, continue. So it was a software developer on your team that was a champion?

[00:25:58] Dianne: Yeah, so he was on the other team, the other team that did that accessibility-specific project. And so yeah, he was responsible for getting the testing framework into our code base, which was a really huge piece of the puzzle.

[00:26:12] Host: Yeah, no, that was really amazing. We are out of time, but I might ping you a few questions for social to put on afterwards, because there is a number to go through. So thank you so much, that was really, really amazing, and I hope people enjoyed it. My only thing is, I wanted to see your cat for the Q&A.

[00:26:34] Dianne: She's been very noisy, that was a challenge.

[00:26:38] Host: And it's 6am in the morning in New Zealand, so we really, really appreciate all of that. So I hope your day goes as well as this has gone. Thank you so much for that.

[00:26:49] Dianne: No worries, thank you.