Accessibility is not an add-on feature—it’s the product itself

Clips–audio and video recordings—are a great way for teams to share detailed information in Slack without having to put a meeting on their calendars. When we updated our platform to transcribe clips automatically, the change became a hit with users. Some enjoyed the added focus time they got from quickly glancing at the transcript, and others liked the convenience of being able to revisit the Clip for future references and pulling important points from it.

But the change wasn’t initially created for efficiency and convenience. It was intended to bridge the gap for hard-of-hearing and deaf users. For people who rely on accessibility to use a product, there is no product without it being accessible. That’s why I believe accessibility is not an add-on feature—it’s the product itself. A product without proper VoiceOver support, for example, is nothing more than a screen that says “button, button, button” to a VoiceOver user.

As an accessibility-focused engineer, I’ve leaned into some important ways of approaching accessibility from this mindset.

Ask the right questions

New product or feature ideas are often created with primarily abled users in mind. That’s why it’s crucial to ask accessibility questions from the start of a new or updated product idea. I like to break my questions into two categories: logistical and technical.

Logistical questions are straightforward. Questions like if a user is blind or low vision, how will they perceive the screen? How will they interact with the product? I repeat these questions for different abilities while also considering how mobile versus desktop use will impact those interactions.

These questions may feel overwhelming for startups and small businesses to consider, but gaining perspectives from communities with varying abilities is a good starting point. One way to do so is to look for resources from creators with disabilities like James Rath and Molly Burke to gain a deeper understanding of the fundamental, logistical aspects of how they experience the world, and ways you may be able to alter your products to serve them better.

Companies should also consider having accessibility experts on staff who can help guide these conversations and answer these questions. But to build a true culture that understands the varying experiences of users, companies should think about hiring people with disabilities directly. Actively recruiting or partnering with companies like Fable or Prime Access Consulting, which employ people with disabilities to test and do user research on products, is how to ensure your products work for everyone.

Technical questions

Regarding technical questions, it’s important to consider precedent or what’s been done before. Are there patterns in the industry for making this kind of product more accessible? This question is important because that’s what your customers will be used to. Take large-text mobile users, for example. It’s common to shift horizontal layouts to vertical ones when the text size hits a certain threshold. This allows the screen to accommodate the larger font without cutting off words for users.

Without precedent, we can ask, “How do we innovate for this?” And if we need to innovate, it’s a good time to talk to our users and ask questions like:

• Given the current functionality of this product, what would be helpful for you?
• How would you like to use a feature/product like this?
• Are there any obstacles we haven’t discussed yet? Are we missing something?

Asking users directly can be powerfully informative. It’s how Slack gained a better understanding of a verbosity challenge with its screen readers. Because Slack is very content-rich, screen reader users end up with overwhelming informational output. The main goal of our product is to make work more productive, but we realized our information architecture was making work less effective for some. We’re currently working on a range of new improvements enabling users to have more control over how they consume Slack content via their screen reader, and we’re excited about it. Talking with the community helped us better understand what users actually wanted in this space and gave us insight into how to solve it.

Consider conflicts of interest

Good intentions to solve one accessibility obstacle for a particular group may end up hindering another, which is one of the most challenging aspects of improving products for everyone. Let me give you an example.

While I was at X, formerly Twitter, we got feedback from some of our screen reader users that they wanted to hear “hashtag” instead of hearing “pound sign,” because really, it should be “hashtag cats,” not “pound sign cats,” right? So we moved forward by making the change and got more feedback, but this time from a different user group. Braille users shared that the transition to “hashtag” ate up more cells on their devices than “#”, ultimately making tweets more difficult to read.

While these two user groups are both blind and low vision, they have different needs based on the assistive technology they use. What did we ultimately do? We kept the “hashtag” change to serve our screen readers users, but also added a setting to our accessibility menu to turn off that change for our braille users. Users now have the option to choose what works best for them.

Like one-size-fits-all-clothing, one-change-fits-all for accessibility is a well-intentioned idea, but it often doesn’t work. That’s why giving users the ability to customize is essential.

Use the hub-and-spoke model

Startups and small businesses may not have the resources to appoint a large accessibility team like Apple or Google, and this can be challenging because accessibility requires breadth. You need product managers, engineers, designers, experts and user test groups working in sync.

The hub-and-spoke approach is a model that can work for companies of all sizes. At Slack, we’ve implemented this where the accessibility team is the hub (or core), and the spokes are members of other teams across the company who act as accessibility directly responsible individuals (DRI) for the products. This lifts the responsibility solely from the core accessibility team to write all the code or complete all the implementation work required to make products more accessible—empowering the accessibility team to spread awareness and work side-by-side with designers, engineers, and others. This approach can be instrumental for lean accessibility teams to get the resources—and attention—they need to make products work for everyone.

The other great benefit? It helps companies move away from the mindset that accessibility is an add-on feature or afterthought. When you raise awareness and involve all departments from the start of every product development project, you instill accessibility into the product itself.