Maximising Impact: The Strategic Role of Tech Leaders in Leading Accessibility Efforts

So I'm here to talk about accessibility. And when it comes to accessibility, most people are in favor of it. I don't know most of you in this room yet, but I do believe that you're a good person. I believe that the people that you work with are also good people. Accessibility, though, ends up falling into the - Oh, let's turn this on. (Adjusts mic) Oh, of course, I should plug this in. It would be helpful - It often falls into the 'too hard' bucket. So can you tell me, for example, why does it fall into the too hard bucket?

What about accessibility is too hard? This is not a rhetorical question. (Audence member): You have already built things wrong? MM: Things were already built. Yeah, so it's hard to retrofit it in. What else makes accessibility difficult to accomplish? (Audience member answers, inaudible) So we're not aware of the accessibility needs of the people in our team, so the empathy is not like.. making that empathy, yep.

Anything else? Sorry? (Audience member): 'Convincing leadership'.

MM: Convincing leadership is important. Cool, so we're gonna talk about that. So yeah, there's all sorts of reasons why we put accessibility in that too hard bucket - from competing priorities, to things that have already been built, to perceptions of cost. But when we put it into the bucket, we're putting other things as well. So we know that accessibility is prevalent or disability is prevalent. In Australia, one in five people have a disability. Put in other words, that's five million people. Or put in other words still, that's the entire population of Melbourne. And accessibility is not just good for people.

It's not the warm fuzzies either. It's good for business too. 63% of organizations believe that improving accessibility improves benefits for all users. And organizations that invest in accessibility see 28% higher revenues than their competitors that don't invest in accessibility. So when we're taking accessibility and we're putting it in that too hard bucket, we're putting other things into that bucket as well. So how do we prevent that from happening?

How do we implement accessibility, get all the benefits, help our users?

And that's what I'm here to talk about. So I broke down this talk into three topics or sections. It's the 'why', the 'who', and the 'how' - or the 'what' is what it is. So let's talk about the WHY. And specifically, this is talking about how you talk about the why, about the convincing others. So as humans, we make - and people - we make decisions with head and heart. And you can decide for yourself or for others exactly what that division is like. When it comes to business, and we already heard a lot about making decisions, when it comes to business decisions, almost always it boils down to three main things.

And of course, businesses are made up of people, but it usually falls into these three categories. It's about increasing revenue, reducing cost, and mitigating risk. So whenever you're making really any sort of case that you want to make to your leadership, if you take that argument and you break it down into one or more of these three categories, you're going to be a lot more convincing, we'll say. So let's talk about accessibility and let's break that down.

We'll talk about revenue first. So I have an example.

So I'm based in New Zealand. And whether you've heard or not, there's an energy retailer called Flick Electric. It just got bought over by another major retailer. So now all the customers from Flick have to go somewhere else. So Flick was one of those more smaller independent organizations. And so their market share was about 1.8%, not huge, but it was made up of - sorry - that 1.8% is still 41,000 people. So that's 41,000 paying customers who need electricity and where are they going to go? One of those people is, in fact, one of my colleagues who is fully blind. And so he was with Flick because he can pay for his electricity online. And we were having a chat and he's like, "Maia, I don't know which provider to go to anymore because it's not accessible." He uses a screen reader and he can't access it. For example, I have on screen one of the retailers, this is their join site, and I have highlighted an input checkbox that has no label. So how is he using a screen reader supposed to know what box he's ticking in order to sign up for this retailer? I'm, for example, with this - another energy provider that uses graphs to communicate how much power you've used, how much power you have left, that kind of thing.

And they use red and green to indicate that. But red and green is the most common form of color blindness.

8% of men are colorblind, and that's the most common form. So it's limiting for those kinds of users. I also have a video. We'll see if it shows up. This is on one of the retailers using a tab, I'm tabbing through, and you can't see the focus state. So I'm in the nav first.

And then as I go through the body of the thing, you can't see where you are. So this impacts power users who are really comfortable using their keyboard, as well as low vision users, as well as screen magnification users, because you can't see where you are.

So all of these people have to go somewhere, and this is a really clear example of how the disability community represents a valuable and underserved market segment.

We can take this to other pillars as well. When it comes to operating costs, bolting on accessibility is a lot harder to do than building it in from the beginning. And in fact, you don't have to believe me - IBM has done a study. Back in 2008, they found that finding a bug in production - so you can say an accessibility bug in production - costs 30 times more than if you catch it earlier on in the design phase.

So there's costs that are-- and then if you're getting somebody like me coming in to do consulting, it's gonna cost a lot more to have me consulting over something that is much more broken than something where accessibility has been built in from the beginning. And then finally, when it comes to mitigating risk, that's our third pillar. In Australia, we have the Disability Discrimination Act - it was just updated this past year, or last year - which says that you cannot discriminate against people for disabilities. There's a famous lawsuit in Australia of the Coles supermarket that got sued in 2018 for not being accessible. And that's just in Australia.

Globally, the standards are actually much higher and much stricter.

And so in the US, for example, where everybody sues everybody, we saw last year over 4,000 lawsuits in the US alone. And the EU has just released the European Accessibility Act that just makes the requirements even higher. So if your organization or your company or your business is already international or is planning on going international, this is a risk that you need to be thinking about in order to mitigate.

So that's pretty convincing, yeah? So now that you've made the case and, oh yeah, I have an infographic here. So if you want more of these stats, I have an infographic on the website, there's a QR code. If the QR code doesn't work, you go to alephaccessibility.net/resources for more of these kind of stats. All right, so those are the three pillars that we're taking our accessibility case and we're fitting it under. And now that we've convinced, you know - and this is a conversation that you're gonna gonna keep having, but if you're fitting it in within these categories, you're gonna make a lot more convincing case. All right, let's talk about the WHO. So you've got people on board, now who's responsible? When it comes to accessibility initiatives, a lot of the time we see them failing, because it's often one person. So you have one dev who, what we'd say 'caught the accessibility bug', and found it really interesting and exciting, started doing a bunch of research and learning, maybe even went on a training course, started implementing it in their own work. Maybe that person even got other people on board as well. And so in their team, there's a lot of enthusiasm for accessibility. But that person as an IC is still limited in their influence to just their team, right? So there's still teams that exist outside of them, relationships that they don't have, connections that they don't have with other parts of the organization for them to have that kind of influence. And what ends up happening is that one individual person might slow down because they have other things going on personally or professionally. Maybe they're a bit burnt out because they've been carrying this accessibility issue all by themselves, and they just kind of want to take a break.

And as they slow down, then other people in the accessibility initiative also start to slow down. And then, and/or, maybe they leave just as a natural part of churn, maybe. And so with their enthusiasm, so does the accessibility enthusiasm go. Now, this is, you know a 'too bad' kind of thing, and it's for it - to see an initiative ramp up and then slow down. But one of the other problems as well is that it's yet another thing that gets added to the bucket, the too hard bucket, because 'we tried it before and it didn't work'. So instead, what we're going to do is - we've got you in the room, right? So there's a difference between you and an IC.

For one, you have different influence.

Even if you don't feel like you do, by nature of your role, you have different levels of influence than an IC does. So for example, you're vertical alone, you can have greater influence, or at least a lot easier influence to influence that vertical.

You also have relationships across as well and actually above you too, right? That even if you again don't feel like you have a lot of influence with those relationships, having those there can allow you to start broadening the reach of the accessibility initiative, giving you access to different people and different contexts to where they're coming from. Now there's also another thing that you have and - yeah, there's also another thing that you have, and you're gonna say it with me, one, two, three, 'too much to do!' So because you have too much to do, you're not gonna do it on your own. Because what you do have is leadership skills. You have things like delegation, management skills, collaboration skills. You can empower other people, you can mentor other people. And it's with these leadership skills that instead of carrying the entire accessibility initiative all on your own, is you're going to build a community of practice. And now a community of practice is really valuable for a lot of different reasons and sharing the load across a lot of different people. You know, many hands make light work, finding motivation in other people, those are really valuable - knowledge sharing. That's all part of having a community in general. We're talking about accessibility specifically, and there's two things I really want to highlight about the value of a community of practice, specifically about accessibility. For one, I think you're going to be surprised by how many people come out of the woodwork. Cross-functionally, you're going to find that there's a lot of people at your organization that have been thinking about accessibility already, that maybe have been implementing accessibility already, that have been reading about it, that have ideas and have their own enthusiasm for it.

People you had no idea, and I would not be surprised if that was the case. So, building a community of practice is really going to pull those people together, and that's how you're going to find shared community and shared motivation with each other. The second thing that's really important is about identifying allies.

Accessibility is inherently cross-functional.

For example, you live in your vertical of dev, and you can get your dev team to be superstars when it comes to accessibility.

But at the end of the day, if the designs that come in to your team are not accessible, then you're always going to get, you're always going to stumble and hit blockers. So inherently, you need to know who is in the organization that you can lean on and that you can work together with. For example, when I was working at one organization as the accessibility person, it was the QAs. So I would run forums and community practice meetings, and the QAs were coming time and time again. They just could not get enough of accessibility.

And even though I was in the dev team, I really struggled to pull the devs in. And so I was like, okay, those are my allies. So I started working with the QAs. We started working on test cases and having them be the kind of the final line of before things get out that they'll at least be that barrier before release to make sure that we're building accessibility in. So if I didn't have that community, I wouldn't have thought to lean on the QAs. And so that's the point of this is you get to identify, you know, is it all the designers that are showing up but not the design lead? That'll tell you something. Is it, again, all the QAs that are showing up and their lead and, you know, that'll tell you who you can lean on. Okay, so you've rallied the troops. Now what do you do?

So one of the things about accessibility is that it's really overwhelming.

There's a lot to do. And I can tell you I'm in the industry and there's always something you can do. So what do we do when there's something that is too big to handle in one big chunk?

You break it down. Right. And so this is what we're going to do with accessibility is we're going to create a roadmap in order to tackle small pieces at a time. And in fact, this is really critical.

In a report that was done in New Zealand and Australia, it was found that the single biggest step an organization could take was build an accessibility roadmap. It didn't even say what was in the roadmap that mattered, but it's simply having a roadmap there, having goals and people taking ownership and seeing it through. That's the thing that actually matters because there is so much that you can do.

Okay, so we have our community and that's who we're gonna lean on and we're gonna use them. Again, you're not doing this on your own. You're gonna lean on your community in order to create that roadmap together.

There's all sorts of things that you can do in that roadmap.

And again, we'll focus on accessibility, and I'll just give you some tips and advice, if I can, in accessibility. So I would say that there's a few different accessibility focus areas. I'm not going to touch on all of them. I'll just read them out or, yeah, anyway.

So with some focus areas like job roles, for example, you might focus on just your vertical or, like my example, where I was working with QAs, so I was focusing specifically on the QAs, right? One of the critiques about the 'too hard' with accessibility is you got so much legacy code. How are you going to work on all that legacy code and make it accessible? My answer is don't. Don't focus on the legacy, at least not right away. Focus instead on the new features, focus on the new areas, maybe something that's two years and newer, that kind of thing, on your design system.

Anytime that there's changes or the design sense is really fundamentals you can focus on that rather than on all of the legacy stuff, right? Breaking it down, don't do the hardest thing first. Get those low hanging fruit instead. Training and awareness, like what is accessibility? You know, how do we like put the guardrails around it? That's totally legitimate, you know? Get somebody in your crew to figure out what accessibility is to your organization. And this is where lunch and learns and stuff can come in as well.

So of course process is one of those areas as well. And I just want to zoom in on this one a little bit. This is where automation comes in.

And it's particularly true for tech leaders because we have so much control, like there's so much automation available to us. So again, I have a QR code with free accessibility tools. The great thing about automation is that so much of it is free. Who here has automation, accessibility automation in their - anywhere in their coding, like whether personally or part of the wider thing?

Okay, cool. So some people, yeah. So if you did not raise your hand, then your homework - congratulations, you have homework - is to pick one of these these things and then start to include it. And if you, even if you did raise your hand, actually, you're gonna pick something else and you're gonna start doing that. And so what we have on screen is things like a testing suite that plug and plays really easily. And you could set a lot of rules around it. Linters, you got browser scanners. You can even talk to your dev team and get, design team, sorry, and get them to use some Figma plugins, all sorts of tools. You pick any and you make it work. So that is going to help your process build in that baseline of accessibility.

Automated scanning doesn't catch a lot. Like, for example, we saw the-- when I was tabbing through that website and you couldn't see the focus state on it, automation is not going to catch something like that. It catches about 10% to 30%, which is like, not great.

But you might as well catch something, right? You might as well build that safety net and that baseline there. Yeah, so just a few other things. You can go by accessibility categories. So talk about like keyboard navigation, 'we want to focus on keyboard navigation', or color, things like that.

Procurement, if your company does that. Policy: do you have an accessibility statement?

Maybe you should write one. Even if you aren't achieving your accessibility goals, maybe write one that says, 'I care about it,' and then that starts the plan moving forward. And then establishing a baseline. A Lot of organizations find it useful to just do an audit. And then you get a really specific way of knowing where you're doing well and where you're not. And it just gives you some sort of starting point - that's establishing a baseline.

Okay, so yeah, and I have a resource again. I'm like throwing resources at you. I'm trying to tell you that it's not that hard. Okay, so there's resources as well for creating a roadmap template so you can work with your community and make it happen.

Okay, now one part about making a roadmap. So I was talk.. I was chatting with a CTO of a medium-sized startup a few weeks ago, and he was telling me that he is really passionate about accessibility. He has family members who are, like, have disabilities. And so something that really hits close to home to him. But as a CTO, he's still finding it really difficult to get some traction and get executive buy-in. So we were chatting and I was like, "Oh, yeah, you know, those are like pretty common feelings. I totally empathize with that." And I was like, "you know, tell me more about what's going on at your organization." And he was like, "yeah, you know, all we're doing is, you know, we've tested all of our colors for color blindness, so we've checked that off, you know, and all of our colors, they meet color contrast. And, you know, we're working on keyboard navigation now. And we do have accessibility sprints going on, you know, so trying to implement accessibility more and more." And I was like, "Whoa, hold the phone. You're doing all of those things?" And he's like, "Yeah." And I'm like, "And you're still getting difficulty with buy-in and getting people on board?" And he's like, "Yeah." And I was I was like, "Well, are you reporting on it? Have you documented these anywhere? Do you have a policy that outlines that these are the things that are going on? And he's like, "No." And that's another key part of this roadmap that I want you to also include.

I'm sure that your jobs all include some level of reporting, whether it's formal or informal.

Include accessibility in that reporting.

Include it regularly. So you say, you know, whether it's a fortnightly, monthly, weekly, whatever: "Here's the status of what we've been doing with accessibility." Everybody wants to be on a winning team.

Everybody wants to know the progress. Like I said at the beginning, people are doing it - are not doing it, not because they don't care about it. And you can include even the smallest wins either - as well, because it's the small wins that add up, and they tip the scales. So even if it's just like, you know, a small, you know, we defined the scope of what accessibility is, write it down, tell people about it. Because again, you're building your case and you're building that momentum and you're crafting that story about "here's how we are implementing accessibility." Because like I was saying, people aren't doing it - just like you, people are not not doing accessibility because they don't care, because they're bad people.

They're doing it because it's too hard. The perception is that it's too hard. And so instead of focusing on what's too hard, and instead we focus on the momentum that we're building, on the fact that we have a roadmap that we've already accumulated success, we have some smart goals, and we've implemented automation, all these kinds of things, it rebrands accessibility from being something difficult to something that we're actually achieving and something that we can actually hop on a bandwagon and start moving forward. Because really, that's what this whole thing is about. It's about looking at that too hard bucket and saying, "How do we tackle this?" And hopefully, by thinking about the ways that we talk about accessibility and thinking about the language that we use and crafting stories in a way that is speaking other people's languages, that we build community and that we find energy in other people's energy as well. And when we create a roadmap and then we share the successes that we have in that roadmap, hopefully when we look at all of these assets and all the things that we are doing, we can look at that bucket and we can say, "I don't know, maybe accessibility is not that hard after all." Thank you.