How Slack Builds Accessibility, One Feature at a Time

As companies grow quickly, maintaining standards and best practices gets harder. Whether it’s updating or enhancing products, taking on new markets, or acquiring other businesses, companies need to continually reinvest in their internal systems to keep every customer and employee safe, engaged, and successful. This especially applies to accessibility – the process of designing products and tools so that everyone, regardless of impairment, can use them equally and equitably.  

After Slack’s digital HQ technology joined the Salesforce family last year, we reached out to Prerna Ramachandra, senior product manager of Slack’s design systems and accessibility team, to see how they work toward accessibility, usability, and user equity.

Create a system to vet features for accessibility

When Ramachandra started at Slack in 2020, it was time to shake things up. “We recognized that as Slack grew and scaled very quickly, our processes around ensuring our product is accessible hadn’t kept up at the same rate,” she said. “We needed a new system to vet features before launch.”

Working in tandem with groups across the company, Ramachandra and her team launched a new series of product benchmark tests – and developed a new set of standards to complement their product design system. These new standards gave teams a concrete goal, and the existing design system ensured they could reach it.

 “Think of it this way: We make all the blocks that other teams can use to build their features,” Ramachandra said. “That way, you know the blocks are accessible. Teams aren’t working from scratch. Mistakes still can be made – teams still have to think about how those components work together in an accessible way – but it gets us a big part of the way there.”

Now, while they continue to oversee testing and design, the team also produces a wide range of accessibility enhancements. One of them involved building in mandatory image alternative-text labels, which describe images for users who use screen readers. 

Build accessibility into the code

Product accessibility is built directly into the code of the product. These include things like application programming interfaces (APIs) and end-user enhancements, such as alternative text and assistive text for screen-reader users. APIsare pieces of code that perform basic queries. If you look up the weather on your phone, an API asks a database for the data. This gets exponentially more complicated when apps like Slack integrate with thousands of applications, such as documents, task managers, or even larger data platforms. APIs could potentially pull content from a less accessible source, so an accessible platform might still encounter accessibility issues. In other words, applying accessibility across connected apps is no small feat.

Enable employees to design for accessibility

Ramachandra’s business-level enhancements mostly target individual Slack employees with things like internal training programs and educational materials. “We recognize accessibility can require fairly specialized knowledge,” she said. “We created educational resources to make sure our quality assurance team not only knows what tests are necessary, but why. Things like color contrast, visual zoom things – basically they’re a playbook for everything covered by web content accessibility guidelines – and all publicly available – standards.” In essence, Ramachandra’s team created a cross-organizational accessibility playbook and became the living knowledge base for others to turn to.

Shift perspectives, user test, and lead design with empathy

Even with the measurable improvements made in just a year, Ramachandra aspires to a more universal goal. “We’re starting to look at our practices and needs more holistically – and that perspective shift is the primary focus for this year,” she said. “How do we make sure our design team is empowered to design for accessibility from the start?”

Her answer: Lead design with empathy. Slack’s inclusive design philosophy has three major cornerstones: data, personal relationships, and hands-on training.

First, Slack partners with research companies that conduct one-on-one accessibility and usability testing. They recruit a wide spectrum of users to account for as many individual circumstances as possible, because of the wide range of different types of disabilities people can have. Ramachandra said, “It’s an imperfect process. A testing group of individuals can’t necessarily speak to the broad needs of a demographic – but we really try to be inclusive.”

One-on-one testing provides additional benefits. People often have trouble self-reporting their experience when it comes to repetitive tasks. For example, what are the exact steps you take to start your morning? In what order? Are you positive you did every single one today? When testers can observe users, they can get more valuable information. “There’s only so much you can get from raw metrics,” Ramachandra said. “If we want to see how quickly people are navigating via the keyboard, we can really only see that in qualitative usability testing.”

Get direct feedback from internal advocates and customers

Ramachandra and her team also build and maintain relationships with their employee resource groups and customers for guidance. They often host informational calls about new products and features prior to launch to get feedback and, often more importantly, perspective. 

The team also works directly for and with customers. Slack’s user survey has become a critical piece of its roadmap. “We had some interesting surprises,” Ramachandra said of their June survey. “For example, we had spent time beefing up our help processes; it was one of our goals in creating the Accessibility Hub. But what our users told us they needed was better onboarding. So now our roadmap includes an accessibility onboarding workflow. That came directly out of that survey.”

Ensure an inclusive process to deliver an inclusive product 

Ramachandra’s approach to accessibility training is explicitly empathetic.  “We’re never going to be able to directly translate the lived experience of someone with a disability we don’t ourselves have,” she said, “but instead we can examine the very specific experience of how our technology is used.” 

It’s an important distinction. A major pitfall of many accessibility initiatives involves designing for an imagined ideal, rather than real limitations. “When you’re thinking inclusively and designing for inclusion, you also ensure that you’re not being unconsciously ableist,” Ramachandra said. “You think about the circumstances in which something like Slack is being used rather than creating an imaginary person who’s using it.” With inclusive design, one of Slack’s guiding product principles, the final product is as important as the process that creates it.

For Slack – just like the rest of Salesforce – reaching all-encompassing inclusivity is an ongoing journey. It’s one we’re happy to take on together. We hope you join us.