Articulating and Advocating for Accessibility

I have one technical specialty to speak of: building systems and processes that make technology easier for people with disabilities.

Most people in technology, surprisingly, don’t know what accessibility means. It’s either never come up, or it never actually caught their attention when it did. When I ask an average tech crowd how many have listened to a screen reader, I rarely see more than a quarter of the hands go up. It’s easy to write off that other 75% as being deliberately ignorant, but there are lots of potential reasons someone may not have been exposed to how people with disabilities use the web. We didn’t all learn the same things at the same time, and if you encounter someone who hasn’t learned what you understand, you are the person who can fix that. What luck! Wouldn’t you hate going through life thinking how many times you could have made the difference to someone in their project, or career, or life?

I’m an evangelist not for a product, but for a set of user scenarios that tend to be ignored. My goal is to ensure that people know about their role in enabling the broadest possible audience to enjoy what they produce.

CC-BY Randy Stewart, Stewtopia, filtered.

Here’s how I explain why accessibility matters, in a nutshell:

Technology has the opportunity to be life-changing for all people, but especially people with disabilities. As the builders of this technology, what we do can make it easy for people of all levels of ability to use the things we make—or it can make it impossible.

As access to information becomes more critical to how we lead our lives, it becomes even more important for us to make sure everyone can participate. We all want the ability to communicate with our friends, do our work, buy and sell what we want, and make ourselves heard using the devices, sites and apps we choose. We’re also getting older ourselves, and we need to make sure the next generation of makers learn from our example, so we don’t get left behind.

We know that together, we can make amazing tech that works better for everyone. There are all kinds of resources from education and examples to working code to testing tools and experts who can help. But the first step is simply to become aware of the wide range of people who may be using your products, what obstacles they face, and what you could be doing to move those obstacles out of the way.

There are laws in place that protect the rights of people with disabilities to enjoy many of the same benefits as able-bodied people. But the best protection against being on the wrong side of them is to show we’ve put some thought into it. We can’t level this playing field without your help.

A Framework for Accessibility Advocacy

There are a lot of messages tied up in those four paragraphs. But they all can be broken down into one sentence:

This is the problem and this is how it affects people and you can solve it and if you don’t, these are the consequences.

That’s my template for advocacy. I’ve created this particular frame for a few reasons. First, it allows me to state my case in as positive a manner possible. This is especially tricky when the person or team you’re approaching is responsible for making your work more difficult.

But more importantly, by marking out these things in the order I do, I have the ability to glean some information from the person I’m talking with. I pay close attention to exactly which point in my pitch, if at all, I managed to reach someone, because that information tells me what kind of resource they will be for me on this project and in the future. Different parts of the framework reach different people. Here are some common patterns in the responses people have, and what that means for the role they might play in building more accessible technologies:

The next advocate – This is the problem.

“How can I help?” That’s a pretty good question to be asked. If you don’t need to get that far into an explanation of the problem set before you’ve got someone willing to try to fix it, you may have found someone who can take your story back with them. These are the people who are most likely to be your champions—people who will be your eyes and ears on their teams, alert you to problems as they arise, and even force the issue when you’re not around. These are your people. Treat them well. Support them with everything you have. Let them ask questions, and give them good answers. Good allies are hard to find, and you need to give them all the support they need. Their success is your success.

The problem solver – This is the problem, and this is how it affects people.

If you reach someone with the second part of the story, you’re still in good shape. This person now has the lay of the land, and they understand the responsibility they have to fix the problem. They may not be the next evangelist, but you can now talk problems and solutions without having to rehash the whys and wherefores.

Usually, people like this want to research issues around disability and its intersection with how they do their job. Again, you want to support them however they prefer it. They’re less likely to do advocacy work on their own, but they’re certainly valuable to you now and into the future, and you should remember them.

The hero – This is the problem… and you can solve it.

You may encounter someone who seems interested and motivated to help your cause, but can’t see themselves as being in a position to do so. In fact, just about everyone who touches a product can make a difference, even in ways that are hard to see. Let’s say it’s an intern on a product with hundreds of engineers and millions of lines of code. What can this one person do? A lot, it turns out. Junior employees know they have a lot to learn, and they touch tons of code that is overlooked. That can be mutually beneficial, especially if you can give them something important to look for, and a chance to teach others. People want their work to have meaning, and if we can connect the work that people do to a higher purpose, we can help them find that meaning.

The bargainer – This is the problem… and if you don’t solve it, these are the consequences

So you didn’t turn them into accessibility activists, but you did convince them that it may be in their best interest to follow the letter of the law.

Good work!

Now here’s where it gets tricky. You didn’t necessarily convince them to do what’s good for people who use their product. It’s more likely that they are looking at the minimum they have to do to avoid trouble. This is an uneasy peace. It leads to a kind of rule-by-checkpoint, where if it’s not in the policy document, it’s not an issue. Issues are often handled piecemeal, and by people who probably won’t be well-trained, because it’s an act of loss prevention, rather than quality or social responsibility. It’s also fairly common to see things that had been fixed disappear in a redesign, or even from build to build, because people don’t understand why something was done a certain way, and instead of learning, they blow it away.

This means it’s your job to get them to understand that, as with most aspects of professionalism, they’re going to waste time and money if they don’t actually find a way to integrate accessibility into their work. They don’t need to like it, or think it’s fun. They need to know you’re helping them improve the quality and reach of their work.

Explaining the tenets of inclusive design in the context of what’s expected of a pro takes some finesse. It’s been the motivation behind many bar tabs on my company card. But return to first principles: your job is to make things better, and if you can identify the problem as lax coding or design standards, then that’s where you need to take action.

The obstacle.

You can’t win ‘em all, of course. As you might expect from a job where you’re trying to get people who don’t work for you to do things your way, you’re going to run into a lot of people who would rather you go jump in a lake. These come in two forms: the ones who say so, and the ones who ignore, avoid or undermine you. It’s important to figure out when someone is just saying something to mollify you, and isn’t actually in your corner, because it will keep you from wasting a lot of time on them.

It’s still your job to make these people aware of their problems, even if they won’t be the ones you can count on to fix them. But you’re a lot better off finding someone else to spend your energy on. Sometimes that’s the designer or the engineer who reports to this person. Sometimes it’s a peer.

If they’re the single point of failure on something you need to be changed, however, you may need to appeal to someone higher in the org chart. It’s one thing if the failure is systemic—that is, if nobody in charge wants to make change happen. But if it’s just one person or team, this is a solvable problem. You just need to find the right people and formulate the right approach, which would include finding ways to make it easier for them to help you reach your goal.

Fighting fires

“Be the fireman, and not the cop.” That’s John Foliot’s advice to accessibility advocates. It’s entirely too easy to knock down someone’s door and tell them they’re violating civil rights law. But even in cases where that’s true, it’s not likely to bring someone along to your side. Engineers in particular don’t respond to this approach: most often, they’re the ones whose work is most carefully tracked, and if your request were genuinely an issue, it would have come to them in the form of a work order. What’s more, when the worst case does come to pass, it’s usually upper management who needs to handle it. What an engineer needs is not a threat: it’s a way forward.

What may be surprising is that this is usually the case for everyone you’ll encounter in a work environment. Everybody (once you’ve laid it out for them, at least) should understand that they have a role to play in achieving the greater goal. If you’re talking to quality engineers, introducing the prospect of doing an accessibility review may be terrifying, because they aren’t experts in any of the tools people use, or even knowledgeable enough to be able to choose from a wide array of automated tools and procedures that are already out on the market. This requires some learning, as it does for everyone in the process. What matters is how you, the evangelist, prepare them to succeed.

Evangelists aren’t experts in all aspects of tech. Nobody is. But one of the most important things you can learn is how stakeholders see themselves and their jobs, as a piece of the larger organization. You are the person who’s motivated to make the organization move closer to your goal. What you are not, usually, is the boss. So you have to lead by example. If someone is stuck with a code problem, you shouldn’t necessarily know how to solve the problem yourself, but how to put the coder in touch with someone who can. If a product manager is telling you they don’t think their users are experiencing an issue you report, find people who can vouch for you.

At times this will seem like you’re working at odds with your organization. You may have to check to see that you’re not actually burning bridges when you think you’re building them. But you should always seek to understand why someone is putting up a barrier so that you can see when it’s time to either push through, work around, or back off. This is hard, egoless, often frustrating work. It is a game that you win inch by inch, and above all, as a team.

The team mentality extends to the resources you compile to get things going. You aren’t likely to have a ready answer to every problem you find, but there are lists upon lists of pros who are willing to share their advice. You should use them. You should also keep up with which consulting companies have good reputations, what tools are on the market, and share what you know publicly as well. A good community of practice is going to get you through the problems you encounter, be they technical or personal in nature. Never neglect the value of community.

Finally, I want to warn one last time against letting events get you down. You cannot solve the world’s problems on your own. If all you can do is point the way, you’ve done enough. It’s entirely too easy to say that people don’t “get it”, whatever “it” is, or to unload on one person for the sins of the thousand who’ve asked the same question before. You can’t do that. It reflects poorly on you and your cause. We are the builders of bridges. What matters more than anything is that we put our issues aside, make our case, and deal responsibly with the work that comes our way as a result.

As evangelists, we see hard problems, and we find people we can work with to solve them. There is no one way to do it right. The only thing you need to keep in mind is that you have a goal in mind, and you can only do it if you bring people along with you, and give them the support and gratitude they deserve.