culture Customers devops Enterprise Strategy management Product Development Thought Leadership

Talking Accessibility: How Teams and Stakeholders Collaborate to Make an Accessible Product

A good product is accessible and inclusive, but building products takes a village; therefore, product teams and their stakeholders should be in the conversation and aligned on a plan to deliver an accessible product. This blog covers the principles and talking points for how a product team and its stakeholders should approach accessibility.

What is accessibility and why we should all care?

Digital accessibility is designing and developing software products that are usable by everyone, regardless of how they might interact with digital content. In practice, accessible software might look like an application with sufficient color contrast so that content is readable without strain, or call-to-action buttons are large enough that users with a minor tremor don’t struggle to click. Accessible software can be navigated without a mouse or a traditional keyboard, and it plays well with assistive technology, such as screen magnification, screen readers, voice assistants, and other head/eye tracking systems. By ensuring that every piece of software we put out into the world is accessible, we can create an inclusive online environment where access is equal and universal and no one is left behind. It is an ethical responsibility, and it also happens to be the law, whether you’re developing a government webform or a private start-up app.

Designing and developing any type of software takes a village, and it’s critical that everyone in that village is on the same page—that the team on the ground adopt accessibility best-practices for user research, continuous testing, and product development; and leadership supports the team to remove roadblocks, cultivates talent in the accessibility community, and unifies team under a shared vision that prioritizes accessibility. When the core team and stakeholders aren’t aligned, work takes longer and progress gets delayed due to inefficiencies. And if stakeholders are really far off, then the product risks being unusable, missing entire groups of users, or not meeting a key business goal, and that is not something anyone wants to find out late in the game. It is much more expensive to remediate an inaccessible app later than to practice accessible product development from the start. An inaccessible product might also get sued for noncompliance and/or discrimination, and lawsuits are very costly in money, time, and reputation.

Key principles to remember

So what can we do? If you’re an individual contributor reading this, then you have the opportunity to engage your stakeholders early and often to get them to see why accessible development is critical to product success. If you’re a stakeholder, then you can proactively make decisions toward an accessible product and support the team’s effort on that. Here are some key principles to stay oriented while navigating this.

Start accessibility early

It should be evident by this point that it’s most beneficial to do a lot of this alignment early on and plan accessibility as part of your process from the start. Because many decisions to make a product accessible are the same as the decisions to make something intuitive, user-friendly, or meeting the needs of your users, and accessible development is built as part of code, the development process is closely intertwined with accessibility work. If you have to come back to remediate something that’s inaccessible later, there might be a lot of tedious refactoring.

Keep communicating

Laying a good foundation is just the start. To maintain strong alignment around accessibility, frequent communication is critical. To this end, the team might report progress on accessible features, share user research insights that touch on accessible needs, and/or escalate any asks or helps on things blocking its ability to do good accessible work. Likewise for stakeholders, seek out updates from the team, proactively help them unblock any obstacles, and keep telling the narrative behind why the product that you’re making should be accessible.

Leverage existing allies and champions

If you’re working in a large team or organization, there’s a good chance that someone already understands the importance of accessibility, has a lot of knowledge around how to develop accessible software, and/or might be an accessible user themselves. Recruit them to get their feedback regularly because the landscape of getting accessibility right is pretty vast, and it helps to have someone answer questions, help you advocate, and maybe even test your application along the way. And if they have organizational clout, that is even better!

Figure out legal stuff

An application is either accessible or it’s not, because all it takes is one misstep for it to be generally non-compliant. Global laws determining digital accessibility—including Section 508 of the Rehabilitation Act and the Americans with Disabilities Act (ADA) in the US—all refer to the Web Content Accessibility Guidelines (WCAG) with three levels of conformance: A, AA, and AAA. Most laws set conformance at the AA level with WCAG version 2.1. All that being said, don’t just take my word for it because I’m not a legal scholar; instead, consult the legal team in your organization and understand your requirements at the federal, state, and/or local level, whether you’re building software for government or private companies. Then you can better chart your path toward compliance.

Get beyond legal

Being lawful is important, but the law is the floor (or bare minimum), and accessibility is so much more than what’s defensible in court. It can be part of the organization’s ethics and culture of inclusion, and building with accessibility in mind can itself become a good team habit over time. We are often putting a solution out there to help a group of people fix a problem or enable them to better accomplish something. When we recognize that delivering value and impact to these people is inextricably linked to delivering an accessible—and therefore, human—product, it is easier for us to see the value of accessibility.

Things you might hear and how to respond

Over the years of working in software design, I have heard and been part of many team-stakeholder conversations around accessibility. With that knowledge, and together with our team at Tanzu, I compiled a selection of approaches and talking points that you can refer to the next time someone brings up accessibility.

“We don’t have users with disabilities, so we don’t need to worry about accessibility.”

  • Acknowledge the work already done to understand the user community and try to learn more about the research process. More often than not, this is because accessible need has been narrowly and stereotypically defined, such as complete blindness, deafness, or missing a limb. Invite your team or stakeholder to broaden that definition to include a broader spectrum of the types of accessibility support needed: permanent (e.g., someone with total vision loss), temporary (e.g., someone forgetting their reading glasses), or situational (e.g., someone using the device under a glaring sun). Include not just physical but also cognitive needs such as dyslexia, ADHD, or mental fatigue. When we consider accessibility broadly, we can build something that is valuable to all of our users in different scenarios.
  • The team should now do the work to understand the different accessible requirements and assistive technology already in use. Talk to users, conduct contextual inquiries to observe their workflows, and use inclusive design artifacts, such as a customer journey that maps user needs. New learnings here would be great to share with stakeholders—they probably want to know what users are saying, as well as how they are using the product.

“We have a QC testing team for accessibility and they’ll tell us when something’s wrong.”

  • Celebrate that there's enough resources for an accessibility testing team!
  • Remind everyone that accessibility should start as early as possible. Accessible decisions are good product decisions, so you’ll want to get those right early on so that we’re not refactoring big parts of the application later. Prevention is better than remediation!
  • Use this opportunity to enable the whole product team to adopt good accessibility development practices.

“We don’t have funding for tests or audits.”

  • Identify the resources that you do have and brainstorm with the team on how we might use those resources to get to where we need to be in regards to accessibility. Maybe it’s worth it to have a separate vendor do audits for you, but that is one of many ways to be compliant.
  • Obtain a quote for an accessibility audit, because they might be cheaper than the stakeholders had feared, and they are a great way to get a professional group of reviewers to tell you what is inaccessible about your product. Just be mindful that most audits use the WCAG standard, but there might be accessible needs (e.g., situational and/or cognitive needs, as described earlier) that the standard doesn’t cover, or that the audit won’t catch.

“What’s the minimum we can get away with?”

  • Understand why you might be constrained to only aim for a minimum, and understand what that minimum looks like in practice. This might mean facilitating a session with the team and stakeholders to align on business and project needs. There are likely underlying leadership concerns and fears at play, and it could be productive to surface these concerns and fears and discuss what is feasible to address them.
  • Facilitate a risks and mitigations exercise to identify risks. If allocated resources truly only permit the bare minimum in order for the team to reach its goals, it is imperative to know the ways that the product might fail and prioritize addressing those that are considered scariest.

“We can’t make an accessible change to this feature because of this reason.”

  • Investigate the root cause of this thinking. Sometimes, what’s said as the reason might not be the actual cause, so try to respectfully dig deeper. If the team and stakeholders are on the same page regarding what’s truly causing pain or fear, this is an opportunity to re-frame the problem around this root cause and craft more targetable responses that are also accessible.
  • See if it’s okay to just try it out. Perhaps there’s a quick, lean test that the team can make and put in front of some users to get feedback. This is especially important if the team believes that this change might be valuable to users.
  • If this is an impasse, ask the team whether this is a battle they want to fight. There are likely issues that the team also has to tackle that are important in other ways, so the team should prioritize their efforts. If this gets put onto the back burner, keep an eye on how this decision plays out—not because we want to point fingers if something goes awry (blaming is destructive to team productivity and psychological safety), but because we want to be nimble and fix it quickly.

“As long as the app is legal, I don’t care.”

  • A viable product (as part of the viable-desirable-feasible trifecta) has to be legal, so it’s necessary to think about accessibility. No one wants to work under the fear that they can be sued. Figure out what the legal requirements are and let the product team work autonomously to meet those requirements; however, stakeholders should be supporting the team along the way by unblocking barriers internal to the organization and bringing in resources, such as funding for accessibility scanning tools, audits, and/or accessibility experts as needed. Determine whether audits are needed, and how to align review/audit cycles to product releases.
  • When it comes to accessibility audits, a full product audit might take time to finish, and that could get in the way of an agile team completing frequent releases. It might be acceptable to align audit cycles to only major product releases and use a good faith argument for releases that are not included in audits (that is, because we are doing audits, we are not willfully ignoring accessibility). The team and stakeholders should get together to discuss and formulate a plan.

“Will this delay release?”

  • This is often heard when the larger organization still uses a waterfall process for product releases, or when product work is contracted with rigid terms. You need to understand this timeline pressure, where it is coming from, and what is the expectation (e.g., if it is more important for higher leadership to release an inaccessible product).
  • Remind the team/stakeholders that product decisions that include accessibility are good product decisions, because an accessible product is one that is usable by people in different scenarios. Thus, those decisions should impact the project timeline the same way as any decisions in an agile team employing user-centered design, test-driven development, and lean iterations.
  • If timeliness is a hard priority, come up with a range of options for what the team could do given different amounts of time (e.g., conducting accessibility audits, recruiting users with accessible needs, licensing automated scanning tools, etc.), and have a discussion/exercise to decide together which option(s) the team is comfortable choosing.

“We can’t release it unless it’s tested and proven accessible, right?”

  • Acknowledge that it is always good to ensure that what you put out into the world (or at least release to a specific user group) is accessible, so this is a good concern!
  • Advocate for continuous, small releases to users. You want to get working solutions to users as soon as possible, which is one of many reasons to build and test capabilities in lean slices and push them to production once tested and accepted. You don’t want to spend a lot of time making something perfect before it is released, because then you don’t get the chance to quickly see whether the product is in fact valuable (and you would slowly accrue risk). If being accessible is part of that value—which it absolutely should be—then what you release should be accessible.
  • Since we work in an iterative fashion, the audit or review process to test software for accessibility might happen more slowly. Therefore, consult with accessibility and legal experts to understand accessibility requirements and work out a plan that aligns these reviews/audits to the team’s agile process.

Take action

It might sound like building an accessible product is a valiant effort against all odds, and sometimes it could feel that way. With open and honest communication, alignment on product goals and constraints, and good decisions based on insights from user tests and accessibility reviews, this mountain won’t be so daunting to climb. Over time, and as we continue to advocate for accessibility and the community shares the tools and processes that have worked for them, I hope that the mountain will one day be just a small bump in the road.  

Helpful Tanzu links

Related Articles