I recently attended a presentation by Benjamin Evans, Inclusive Design Lead at Airbnb, on product accessibility and his experience with designing for inclusion. It really got me thinking about how we build products in tech and the inherent biases in product management.
In an environment that prizes “minimum viability” and “failing fast” there’s seldom much of an appetite for slowing down the parade of new features and functionality to prioritize product accessibility. For scrappy startups and budget-conscious ventures, the resources, time and expertise for such efforts are typically not available or deployed elsewhere. At ProductPlan, we certainly feel the challenge of prioritizing inclusive design on our roadmap, and will be the first to admit that we haven’t made our product as accessible as it should be.
But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings.
There’s also both a legal and moral underpinning to investing in product accessibility. The Americans with Disabilities Act requires accessibility, which includes some digital products and is often a fundamental requirement for large enterprises and any government or government-related operation. Furthermore, making a product accessible to as many people as possible is simply the right thing to do—no one should be denied their opportunity to participate in the world and utilize solutions due to their limitations.
But what’s the best way to make accessibility a fundamental element of product strategy? And when is the right time to make it a mandatory requirement and not just a nice-to-have backlog item? Let’s explore what product accessibility really means and how to incorporate it into the corporate playbook.
Elements of Accessibility
Making websites and applications fully accessible means considering the wide variety of users and their various limitations and preferences. There’s plenty of great content that goes into the exacting details of accessibility, but in a nutshell the main items include:
- Text alternatives for non-text content
- Captions or sign language for multimedia with audio
- Audio descriptions for multimedia that has important visual aspects
- Optimized labels and menus for alternative navigation techniques
- Limiting the use of color for informational or navigational purposes
- Supporting larger fonts/zoom
- Adjustable audio controls
- Resizable images
- Keyboard, touchscreen and voice navigation support
- Extendable time limits for text-heavy pop-ups, interstitials, etc.
- Alternative language options/localization
That might sound like a lot, but it’s just scratching the surface. With such a daunting list of considerations, the prospect of retrofitting existing sites and apps could make any product team stick their head in the sand and pretend they’ve never heard of accessibility at all.
But there is a path to accessibility, even for more mature products. It all begins with chipping away at the problem instead of trying to take it all on at once.
A good starting point can be using a free tool like the Web Developer Toolbar to assess just how accessible (or inaccessible) your product might be. From here you can start with the low-hanging fruit to make your product incrementally more accessible.
This can be as simple as making sure every image has an appropriate ALT tag or including subtitles for all your video content. From there you can mandate full support for keyboard navigation and proper usage of semantic markup.
While none of these individual enhancements will make things 100% accessible, each change improves the situation and broadens your potential user base. Carving out a portion of each release for accessibility in the product roadmap can keep inclusion top of mind, demonstrate your overall commitment and guarantee that over time your product becomes more and more accessible.
The Opposite of Inclusion is Exclusion
One way to approach this issue at a high level is adjusting your perspective when considering whether to make products more accessible. Instead of thinking about how many people can use your product, consider how many are still unable to.
A product manager would never bring a product to market if women couldn’t use it, or if it only worked for caucasians. When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”
“The tension with universal design is how you design something that works for everyone in all scenarios, with every contingency,” says Kat Holmes of Mismatch. “That’s one of the challenges of understanding inclusive design when we look at the object, saying, ‘This design is inclusive design.’ In those cases, often what we mean is universal design.”
Indirect Benefits of Product Accessibility
A common trap when thinking about accessibility is pre-emptively limiting the potential audience of the accommodation. The requirement may be to enable access for a specific population, but there are plenty of cases where other customers may also benefit.
“User research revealed that situational and ability-based impairments produced overlapping pain points and user needs,” says Lillian Xiao of Volkswagen. “This meant that solutions designed for users who are deaf or HOH can also benefit those who are consuming video content in a loud airport or cafe.”
Looking past labels and concentrating on use cases broadens the possibilities and expands the target market for accessibility features. This can lead to wider internal acceptance and excitement about work that may have initially been considered “mandatory” but not important.
At Airbnb, the team has seen ancillary benefits from their accessibility efforts, including superior search indexing and usability from making the site ADA compliant, as well as attracting even more users thanks to localizing content.
“I love that design thinking kind of pushes you to go out there, to make these face-to-face connections and in doing so, you kind of have to challenge your own bias and your own assumptions that you make if you are really going to create a product that empowers these people,” says Benjamin Evans of Airbnb. “It forces you to go out into the world and to find people who have specific needs but who often are from very different backgrounds than you. Because you can have a multitude of different people who need to achieve the same goal, but their life stories are entirely different.”
The Measurability Trap
21st century product management and design is fixated on metrics. Will this tweak move the needle? Will this feature increase a KPI? Will this design boost engagement?
Because we’re always chasing numbers and stats, we tend to design for averages. This means we’re making decisions that should improve our numbers overall and not dwelling on how this impacts an individual.
Unfortunately, our rapid pursuit of larger goals leaves specific users with particular needs—the “edge cases” of humanity—out of consideration. In the rush to decrease page load time are we stripping out key accessibility tags? Does the image-heavy landing page for our new campaign deprive the visually impaired of a worthy experience? Does the funky new app UI strand a user that relies on voice navigation?
Until our key metrics include elements of accessibility, inclusion will always take a backseat to the numbers our management team are hounding us about. Which is why getting executive buy-in on the ongoing importance of accessibility (and the metrics to match) is key to making this a priority for the entire organization and not a back burner item.
And while you certainly can make a site or product accessible after the fact, it’s going to be way less expensive and require fewer resources to make it accessible from the start. Plus if you’ve at least made an effort and have a roadmap for accessibility the company is in a much better legal position than having not made any progress at all, should a lawsuit or threatened legal action arise.
Including Accessibility in the Full Product Development Cycle
Consideration of accessibility can occur throughout the entire product development process.
- Start with customer research—Include people with disabilities in your surveys and customer interviews
- Make it a roadmap regular—Make sure each major release includes another enhancement specifically targeting additional accessibility.
- A checklist for every design review—Before signing off on new user interfaces and design changes, ensure you’re not adding any new hurdles for users with disabilities and are instead removing existing barriers.
- Add accessibility to the test plan—Is QA running through their test scripts and scenarios using screen readers, keyboard navigation or in high contrast mode? Add these as requirements to flag issues that occur when using these alternative methods.
- Recruit diverse beta testers—Just like you want testers using different browsers and operating systems, find some testers that rely on accessibility options as well.
Remember, while accessibility support may address specific limitations in a portion of the user base, its benefits extend far beyond those individuals.
“We may not experience being disabled, but we can at least empathize or at least try to experience the same or similar feeling with one another,” says John Thompson of Merrill Corporation. “A more accessible product for one group of people improves that experience for everyone else. Accessibility is more than designing and developing for people with disabilities — it’s about building things that everyone can use and enjoy.”
