Gaining Buy-in For Accessibility in Your Company

April 17, 2018

In my UX role at Amazon, I’ve become a vocal advocate for customers with disabilities by helping team’s think about these customers earlier in the product development process. I use my spare time to run monthly accessibility UX trainings for designers. In these trainings, I give practical ways to consider accessibility in design work — from color contrast to defining screen reader specifications. Out of the trainings, designers become excited to build better experiences. And then they go back to their team…

People recognize the importance of accessibility but are often overwhelmed by the idea of executing on it. They don’t know where to start. As a result, they often forget about the people that are impacted when tools are not accessible. Many teams don’t even realize they’ve forgotten to consider the needs of people with disabilities. Once forgotten, it becomes a struggle to re-prioritize accessibility later against other work.

So what can you do to gain “buy-in” for your team to prioritize accessibility? I’ll provide five practical ways to work with your team to prioritize accessibility.

Build empathy

Don’t expect everyone on your team to have the same familiarity and understanding of what accessibility is or why it’s important. Most people in product development are aware that accessibility is about making your experience accessible. But many don’t realize the importance it can make in the lives of customers (those with and without disabilities). Without empathy, your peers may not understand the importance of building inclusive, accessible products. For me, it requires a daily reminder that I live in a tech-bubble in Seattle and I am building products for millions of people who aren’t me. They have different needs, dreams, body types, racial backgrounds, educations, and yes, different ability levels.

If you feel your team isn’t understanding or empathizing with customers, start by just asking questions about disabilities. How are we budgeting time in the schedule to support screen readers? Who will write the alt text? Can we simplify the text further? Find small ways to bring up questions throughout the process. Ask about the color contrast in design reviews. Ask about screen readers during a code review. As you build trust with your team, you can schedule a meeting to discuss disabilities and assistive technologies. There are many activities you can use to build empathy within your team:

1. Start with Microsoft’s Inclusive Design activities. This includes 16 activities you can do on your own or in a group.
2. Create team activities using Airbnb’s Another Lens tool. These questions allow us to challenge our reasoning and consider the effects of bias.
3. Organize a meeting to watch videos as a team like like How Blind People Use YouTube & Twitter on the iPhone or How a Blind Person Uses a Computer. Again, Microsoft has a list of videos on their inclusive design page. It’s surprising how many people in software development aren’t familiar with how people use different adaptive technology to do everyday tasks.
4. Setup a meeting for everyone to try assistive technologies. The goal here is to have people experience assistive technology and learn about different customer needs. One example is to teach people how to use their laptop’s screen reader. Once they learn the basic controls, cover the screen with paper. For exercise ideas, check out empathyprompts.net.

It’s important to remember that any simulation cannot teach you what it’s like to have a disability. The goal is to demonstrate what the experience is like for people with different technology needs and to identify product opportunities to better serve these customers.

As you start discussions with your team about accessibility, find like-minded advocates. Partnering with others will give you someone to bounce ideas off of, identify new opportunities, and will make you more effective. Struggling to get a PM to prioritize accessibility? Find another PM who advocates for accessibility to connect them with. Sometimes you need to find like-minded advocates who can speak to the importance of accessibility within the context of a different job role’s priorities. Leverage people with different skill sets to help you become a stronger advocate.

Avoid using statistics

Trying to use numbers to get buy-in for accessibility is a losing battle. While some numbers like “8% of Caucasian men are color blind” sound high, often the numbers work against you. The numbers create situations where you’re deciding whether to support the 1% of customers using a type of assistive technology over the 99% of customers that don’t. It’s better to think of accessibility as something like security. You would never release a product that didn’t reach a certain bar for information security. If you found a security issue that could be exploited, you would remedy it immediately, even if nobody has exploited it. Likewise, don’t prioritize accessibility based on the number of people who use the tool today with assistive technology.

Choosing to only make your product usable for one customer segment and not usable by another is discrimination. We must think of accessibility as more than individuals with a disability. Inclusive design can improve the experience for a wide variety of people. Microsoft did an awesome job with their advocacy and materials for inclusive design. Here’s how Microsoft communicates the idea of universal design.

Another challenge against using data is the cost and effort to add accessibility later. I’ve seen several major projects launch without accessibility considerations and it can be costly to add this later on. Further, adding support later means it becomes stack ranked against backlog items. Accessibility is not a feature. Visible labels is not a feature. Color contrast is not a feature. Screen reader labels is not a feature. These are bugs. If a customer cannot use your product for an issue out of their control, that is a bug. Those bugs should be prioritized above developing new features.

Audit your experience

Referring to “accessibility” as a vague term won’t get you anywhere. Without specifics, your team can’t assess the level of effort and feasibility of implementation. If a team can’t judge the level of effort, it’s far more likely they will say no or forget about your request for accessibility. Similarly, if I asked to add a cool animation, but didn’t show what I was asking for, it would be hard for someone to decide whether it’s possible.

Everyone has a role to plan in designing and developing accessible experiences. Here are some key things to consider about each phase of product development:

• Design: Includes color contrast, specifying screen reader text, using accessible design patterns, and reinforcing implementation details like using proper syntax for screen readers. If your product includes video, you should ensure in the design phase that closed captions are provided. Use simpler language, which helps screen reader users, cognitive disabilities, and when English isn’t their first language.
• Product: Includes accessibility requirements in the MVP even if it means delaying a launch. Going back to fix accessibility issues after launch in a headache. This will save you the headache of trying to do this after a large project has already launched.
• Engineering: Use proper syntax such as marking headings with heading tags. You should include ARIA tags, tab-index for traversal order, and alt tags on every image.
• QA: Validate implementation with various assistive technologies such as screen readers, screen magnifiers, and keyboard navigation. QA should use the designs and specs to confirm the alt text, color contrast, font sizes, etc. Check what happens when the font size is increased on a phone, or a browser zooms in.

Use these considerations to start evaluating your products for specific improvements to be accessible.

File bugs

First, audit your experience for accessibility. Next, file bugs.

Once you identify the specific areas for improvement, don’t just ask a PM or engineer if it can be fixed. File tickets for each bug using your team’s usual process (i.e. JIRA). Like any bug, file each separately. This also forces you to be specific about what it means to support accessibility. Filing bugs individually also brings awareness to the scale of issues.

Once filed, follow up on tickets for prioritization. Do not let these slip through the cracks. At least once a month I’ll reply to each ticket asking for an update. While I’m certain this can become annoying, I want to make sure that we do the right thing for customers and that the tickets receive a response.

Improve your process

Frequently advocating for prioritizing accessibility in a roadmap can become exhausting. Can your team make it a goal to not release products with accessibility issues? There are a few ways you’ll need to rethink your process to make this happen.

First, document what accessibility issues your team is agreeing to avoid.

At a high-level, this covers the WCAG guidelines and addresses a variety of sensory and cognitive impairments. Get specific, and make sure you are in agreement about what different disciplines are agreeing to. For example, our design team has an agreement that readability and usability are more important than aesthetics. We adhere to the AA 4.5:1 color contrast guidelines, or higher, on all text below 18pt and a minimum of 3:1. We choose not to use videos in our designs if we cannot have closed captioning. Engineering agreed that products include proper syntax and accessibility metadata so screen readers work efficiently.

Second, create quality checklists for your team.

Create different lists for different roles so each role understands their responsibilities. For example, our engineering team has a code review checklist that ensures quality throughout the project. We have accessibility as an item on that list that acts a reminder of the importance to every engineer on the team.

Third, ensure that QA has a testing plan that includes assistive technologies.

Talk to your QA engineers and ask what are the existing processes for validating assistive technologies. Work with them to ensure that there is a process for ensuring new bugs aren’t released to your customers.

Lastly, evaluate your process when new accessibility bugs are identified.

When you find new accessibility bugs, do a root-cause analysis to address these issues before releasing. No process is perfect so ensure you are evaluating your process to address accessibility early. When you find a bug, look at what caused it and how you can avoid it next time.

Accessibility, user advocacy, and building an inclusive experience is everyone’s job. And it’s not impossible. We must evaluate our own biases and ensure we are creating a better world, not one that excludes or discriminates. Accessibility can be the most meaningful work you do because of the profound impact it can have on the lives of people who live with a disability. Start today by doing a 20-minute audit of your product with a screen reader and filing bugs. It’s easy to start making a measurable impact on your customers.

Source: UX Design