12. Getting Your Team on Board

Written by Tori Gonda

Now that you believe that accessibility is essential, what’s next? You know where to start and how to improve your app’s accessibility. But how can you get buy-in from your team to dedicate time to accessibility? How do you share what you’ve learned and inspire your colleagues to do the same?

On many teams, accessibility is a second — or never — thought. It can be a challenge to find time to make these improvements.

The answer varies from team to team and company to company and depends on these groups’ motivations.

In this chapter, you’ll develop a plan for your specific situation as you read. There is no coding in this chapter, so grab a pen and paper or open a new notepad so you can capture your ideas in realtime.

Recognizing a need

Before you approach your team, you need a rough idea of your app’s accessibility and how much attention the company pays to accessibility. If your team already has an accessible app, you might be one of the lucky few that don’t need to budget a lot of time to improve it.

This step doesn’t require a full audit of your app. Instead, you can do a quick pass with an accessibility scanner and TalkBack to estimate your level of compliance.

Act: Schedule a short amount of time to skim your app for accessibility issues using Accessibility Scanner and TalkBack. If you have limited time, commit to a short 20-minute session to take notes and get a feel for the accessibility of your app.

It might also be helpful to speak to your colleagues to discover existing accessibility efforts or programs. If they exist, you can engage the people involved and gain momentum together. It’s helpful to have people on your side when encouraging change in your organization.

Act: Take note of who to talk to in your company to learn about existing efforts. Make a plan for when and how to approach them. Remember that your prime objective at this stage is to understand what’s there. You’ll construct a strategy for inspiring the needed change later in this chapter.

Once you have an idea of the app’s compliance level, your organization’s dedication to accessibility, and who might be interested in supporting your goals, you can start thinking about if changes are necessary and how to set the change in motion.

Getting buy-in

There’s a good chance that you’ve already identified a need for improvement. Now comes the hard part: influencing that change.

The first two actions you can take to start encouraging change are:

1. Educate others.
2. Make accessibility needs more visible.

Educating yourself and others

Because most companies place minimal emphasis on accessibility, there is also spotty knowledge sharing about how to address it. Most of your colleagues don’t know what it means to build an accessible app or why it’s important. This is where you come in.

You can help your team learn about this topic. You can share tips you learned in your syncs, watch a talk on accessibility in a team meeting, or organize a book club around this book.

Plug into how your team already learns about new topics and try to integrate it there. Once the learning starts, there will be people on your team who are as excited about accessibility as you.

Note: If you’re looking for a talk to watch with your team, check out ‟Increase Your Product Quality Through Accessibility” from RW Talks at https://www.raywenderlich.com/10528194-increase-your-product-quality-through-accessibility.

When you’re sharing knowledge and trying to recruit people to your cause, you need to understand each person’s motivations. Once you know that, you can make a case around the specific aspects of accessibility that benefit them. For example:

• If someone is motivated by profit, focus on how it can increase profitability.
• If they care about user experience, show how accessibility makes a better product for all users.
• If they care about developer productivity, inform them of the efficiencies of building an accessible app.

There are many benefits to building an accessible app, including:

• Widening your audience.
• Avoiding legal battles.
• Making a better product.
• Driving innovation.
• Increasing developer productivity.
• Recognizing revenue potential.
• Treating others with care.

If you need a refresher on any of these points, go back to Chapter 1, ‟Why Accessibility”.

Act: Who do you need to educate about accessibility on your team? What are their goals when they make decisions? Take notes and use your thoughts to inform a plan to help your colleagues learn how compliance can help the product.

A final tip when you’re educating your team: The way you share information makes a difference. Statistics can be convincing but know that data alone is not enough to change minds. You’ll be most effective when you mix stories and data. Stories elicit emotions, and emotions change minds and help your argument stick.

Bringing visibility to the need

Even after people are educated and onboard with improving accessibility, it is still easy to overlook. How can you keep it top of mind?

One way is to sprinkle small reminders and sustainable habits through your day.

If you get an inaccessible design, ask if you can see an alternative that accounts for accessibility. When you’re reviewing code and see something making the app more accessible, congratulate the author. If you learn a new accessibility tip, share it with your team.

You can also advocate for the time in your development cycle to dedicate to accessibility. This could look like making sure accessibility tickets are included in each sprint or including accessibility review in QA. It’s okay to start small here. Every little bit helps.

Expecting pushback

You should expect and prepare for people to push back. People will disagree with you. Be patient and don’t give up when someone dismisses you or casts doubt on your ideas. Put in an effort to address your colleagues’ objections with poise.

One objection you’re likely to encounter is that spending time on accessibility will slow the team down. This is a valid concern. You must be able to continue moving the product forward. You can still mitigate this concern.

Review the points in Chapter 1, ‟Why Accessibility”, that show how accessibility saves time and money over the long term. Try applying these to make a case that the time upfront is worth it for the company.

You can always compromise on how much time to dedicate to accessibility. If you’re initially only able to spend a little time on improving accessibility, that’s a win. Even minor improvements will have an impact on the people they benefit.

Scaling support

You might be wondering how you can scale your accessibility support. You need to keep moving your product forward, even as it or your team increases in size, right? Scaling up your support without interfering with progress is a valid concern.

You have options for how to scale up your team’s knowledge and skills. By combining options that work well for your team, you can ease the burden and make it possible to build out your app without exerting a disproportionate amount of energy to support it.

In many cases, scaling will start with you. Focusing on incremental improvements over large changes, integrating accessibility into your processes, and sharing enthusiasm with your teammates are the keys to scaling.

Staying focused and thinking small

You could feel overwhelmed by the amount of work to do, especially when dealing with a legacy app with much room for improvement.

Try to break tasks down and focus on one small bit at a time. Maybe that means you only work with one screen or view within the screen at a time. Or, you could focus on one criterion at a time.

The key point is that you don’t need to do it all at once. Little improvements add up over time. Find a strategy to break down the work that works well for your team.

It’s hard to get buy-in when you’re asking people to do a lot of work or substantially change their work habits. You’ll find that it’s much easier to get people on board with you when what you’re asking doesn’t feel like a large, imposing change.

Act: Using the information you gathered during the rough scan of your app, think about how to break down these chunks of work into small tasks that would fit into your team’s workflow and processes.

Integrating into your process

You can also lean into your existing processes and automation to keep accessibility top-of-mind and reduce the burden on your team.

Find ways to use what you already have:

• Do you have a PR template? Add an accessibility reminder, checklist or explanation step.
• If you have a success criterion template, add a note there.
• Include accessibility checks in your QA step.
• Create and include accessibility improvements in your sprint planning.

If you have automation, you can also add accessibility checkpoints there. You can make sure you have accessibility linters turned on and required to pass for new code. Set up Espresso accessibility checks. Use the Google Play Console pre-launch reports to uncover accessibility issues in your app.

Be creative about the ways you can improve your automation and processes! Remember to get input from your team as you think through how to integrate accessibility into your workflow. Your colleagues may surprise you with innovative ideas you would not think of, and people are more likely to support new ways of doing things when their ideas become a part of the solution.

Act: Take note of what processes and automation your team uses and how you can introduce accessibility reminders and tasks. Take note of who owns or benefits the most from current processes so that you know who is most important to consult as you develop your plan.

Sharing enthusiasm

When you’re the only one person championing accessibility, you can get burnt out quickly. With some teams, it can take a lot of energy to change hearts and minds.

Find the other people who are enthusiastic about accessibility and try to get them excited before moving onto the others. It’s easier to create a culture of accessibility when you have multiple people on your side.

One tactic that works well to build excitement comes up during code reviews — in these rare moments, you have a captive audience and the ideal context to bring up accessibility. Make the most of these moments by giving feedback on how well it complies. When a teammate makes something that is accessible, praise them and tell them why what they did was positive. If there’s room for improvement, gently nudge them in the right direction. When you give feedback, remember there are many aspects to making an app accessible, and you and your teammates won’t always get it right on the first try.

Tracking improvement

If your company relies on A/B tests or other analytics to inform decisions, someone on your team will probably ask about user tracking.

When considering what to track, don’t even consider monitoring if a person uses accessibility services without their knowledge. This is an invasion of privacy. Ideally, you should never track this behavior. If you do, make sure it’s consensual.

Tracking this information also gives you unreliable data. Some people use accessibility services to turn on their devices or grant permissions to apps such as password managers. There are also many people who would benefit from an accessible app but don’t use accessibility services.

You can still track other indicators. Perhaps one of the most important things to track is your legal compliance.

You can go through a company to measure this or use the Accessibility Scanner or Espresso checks to create a system of measures for some issues.

You can also measure the types of accessibility-related support tickets. This is an example of a qualitative measure. Do any of the tickets suggest people are trying to use accessibility services with your app? Or are the tickets eerily devoid of such issues? How many similar tickets are there? Review and group similar tickets and track how many come in week over week for each type. Over time, you’ll see how changes you make affect the user experience and identify opportunities for further improvements. And you’ll have user-based data and insights to back you up.

Finally, you can A/B test some accessible features, but take caution with this tactic. An unfavorable result isn’t a valid reason to move away from accessibility; adverse results usually indicate an opportunity for improvement. Some people will even intrepret failure as proof that accessibility is a waste of time. Use the insights you gain from the experiment to try something else. There are many paths to compliance.

Key points

• Understand your company’s approach to accessibility before taking action.
• Help your teammates understand the importance of accessibility and how to make your app accessible.
• Keep a person’s role in mind when educating them.
• Know that it’s normal to experience pushback.
• Believe that it’s better to accomplish a little than nothing at all.
• Find simple, repeatable, contextual ways to build accessibility in your existing processes.
• Encourage enthusiasm on your team.
• Track metrics and measures, but don’t invade people’s privacy by tracking who uses accessibility services without express consent.

Where to go from here?

Congratulations! You’ve reached the end of the book. You’ve learned why accessibility is essential, how to make your app more accessible and how to get your team on board — pat yourself on the back.

You’re not done yet. Working towards accessibility is a continual process. You’ll get code or design wrong and learn something new. You’ll come across an entirely new situation in an app to try to figure out how to make compliant. You’ll work with someone new who you can help educate. A new accessibility service will become available. Be patient with yourself as you go through this journey.

As you start applying your knowledge to your day-to-day work, use the headers in this chapter to help you plan. Remember to be patient with others. You can also use the checklist in the appendix in the back of this book to remind you what to watch for and as a starting place for a custom checklist for your own team.