Convincing People to Be Accessible

I’ve broken the suggestions I am making below many, many times. I’m trying harder not to do that in the future.

Product owners and people above them in the executive hierarchy frequently hold the position that current customers and what they want are the most important things to implement in products. Anything that threatens current customer desires is an enemy to be slain, a distraction not to be given into.

When it comes to accessibility, however, this position can be a self-fulfilling prophecy.

Accessibility Owner: We need to be more accessible.

Product Owner: We don’t have customers complaining about accessibility.

Fact 1: Your product is inaccessible.

Fact 2: People with disabilities can’t use your product because your product wasn’t built to allow them to use it.

Conclusion: At least one of the reasons there are no accessibility complaints is that no one with a disability can use your product.

I frequently tell people that receiving accessibility complaints other than “this doesn’t work at all” should be considered a minor victory. That means that your product was accessible enough for someone to identify an accessibility issue somewhere other than at the very beginning. Having zero accessibility complaints is a sign you are doing something wrong.

1. Either the product is so inaccessible, people aren’t even bothering to complain, or;
2. People with disabilities don’t know that your product is accessible and aren’t trying it out.

Convincing people to make a new product accessible is generally easier than convincing them to retrofit an existing product. New products are effectively blank sheets of paper. Processes and techniques are generally more open for consideration. Also, proactive accessibility is an “easier sell” than reactive accessibility. Reactive accessibility involves changing entrenched processes, and all change (even good change) is difficult.

If you are butting heads with a product/website owner who does not want to make their existing product accessible, here are a few things that might help change their mind.

Explore why the individual holds an anti-accessibility opinion

Getting to the bottom of what is fueling the individual’s beliefs that accessibility isn’t important is of paramount importance. Here are a few common root causes:

• They may come from a culture where people with disabilities are viewed as beggars (at worse) or are not treated equally.
• They may not understand the enormous lawsuit risk caused by inaccessible digital properties.
• They may not be equating accessibility as a necessary component for your organization to be satisfying its inclusion initiative. You can’t legitimately claim you are inclusive if you are actively discriminating against people with disabilities by not undertaking the activities necessary to make your products accessible. Some people haven’t connected those dots.
• They may not understand the risk of not being able to bid or procurement scoring penalties resulting from inaccessibility that exist in many public-sector and some private sector sales opportunities.
• Their work/educational history might not include exposure to accessibility principles or universal/inclusive design practices.
• This individual’s behavior may be driven by hidden rewards for getting the product out. Whether or not the product is accessible doesn’t factor into that reward, and may hinder it.

This step requires active listening (which I won’t try to provide advice on because it is not a subject I have even come close to mastering) and uncomfortable conversations. But it needs to happen because it’s difficult to counter objections where you don’t understand the root cause of the objection.

Try to keep emotions out of the discussion.

This is also incredibly difficult for me to successfully do. I identify as disabled (in fact, I have several disabilities, 2 of which are completely invisible). I have a child with a disability. When people say things or take actions that demonstrate that accessibility is an issue they don’t care about, to me, they might as well be saying that they don’t care about what people with disabilities need to have equal access. It’s ableist, discriminatory, and wrong. For me, it is a significant emotional trigger since I’ve faced these types of barriers my entire life. I’ve recently started working with a coach on better trigger responses.

But, calling the individual out on their ableist behavior in so many words is generally counterproductive. You dig in. They dig in. Nothing positive happens. If you can derive what the individual’s objection is and can successfully counter it without changing their world view, that puts you on the path to successful cooperation and an accessible end product.

Choose the approach that you think resonates best for the current circumstances.

These are the three typical approaches that I use to convince people to make things accessible:

1. Accessibility is the right thing to do.
2. Accessibility is a good business decision. A sub-argument of this is occasionally, “we are going to lose deals unless we make the products we sell accessible.”
3. And finally, the nuclear argument, which is compliance. A compliance argument for accessibility typically sounds something like, “if we don’t do this, we are going to get sued, and it will be your decision that caused that.” This argument may involve dragging in the legal department, which is never fun.

The reason why I don’t like number three is that when you resort to that compliance as your argument, you are all but guaranteeing that the WCAG guidelines will be viewed as a goal and not a floor for the product in question. Forget about trying to get best practices and innovative accessibility techniques like personalization approved, those are not part of what is being measured against. Accessibility work beyond WCAG will never be prioritized over other features that customers are requesting.

Show lots of assistive technology demonstrations.

From sixth to twelfth grade, I was in adaptive education in a fairly early integrated mainstreamed setting. I was in a wheelchair or in casts and on crutches almost that entire time. I was grouped with classmates with all kinds of disabilities: polio, paralysis, asthma, autoimmune issues, complete vision loss, and hearing loss, to name a few. Assistive technology has been part of my life for more than four decades. At the beginning of my accessibility career, it never crossed my mind that non-disabled people would have no knowledge of how people with disabilities use assistive technology.

Stories are powerful. When you start a discussion with a product owner about accessibility, initially, it almost always is perceived as “are we going to add this feature?” This initial perception is usually quickly followed by the product owner wondering (either to themselves or occasionally out loud), “what feature am I going to have to give up to make room for accessibility?”

When you start showing demos of assistive technology use, you are subconsciously reframing the discussion to:

– Assistive technology users are capable of using our software if we remove the barriers, and;

– Are we going to discriminate against assistive technology users by allowing our software to remain inaccessible?

It is easier to say no to a feature than to admit that you are discriminating against someone with a disability.

Propose eating the elephant one spoonful at a time.

Accessibility can seem overwhelming to someone new to the subject. By breaking it down into chunks and addressing each chunk in a separate sprint, accessibility seems more readily achievable. Some of the chunks I use are “keyboard,” “colors,” “forms, and error messaging,” for example. It’s easier to think about 13 categories of related guidelines than 50 independent guidelines. Even focusing on a single WCAG pillar is a little too much — organizing your focus around product behavior is an easier way for developers to think about accessibility challenges. Focusing on a limited number of related accessibility guidelines in a single sprint lessens the perceived impact that accessibility has on the overall development effort.

Being able to provide support will also help diminish the effort. If you can, have designated people available to provide training and answer questions that come up as the designers/developers are working on the product.

---

The most important thing is to keep at it. You may not win in the first discussion, or even the fourth or fifth.

• Make sure the word “accessibility” is one that everyone is aware of and understands. You are unlikely to convince people when they don’t know about the issue. Having a clear accessibility brand that speaks for you when you are not in the room will help with this.
• Staff turns over. You may get a more receptive ear than the first one you were presented with.
• Deals may be lost (or not bid on). Try to keep track of those so you can prove the economic harm of inaccessibility.
• Success can help breed more success. If you get one project to be accessible, carefully track the positive outcomes from that work and use it to bolster your argument with your more recalcitrant project owners.
• Complaints may be filed, worst case, lawsuits may be filed. This is not the time to say, “I told you so,” even though you will likely feel like it. Just think it loudly in your head. Instead, say, “I know how to solve this problem, and we should proactively build it into new products in the future.”