Before Sommer Panage joined Slack, there was no centralized team working on accessibility.
Panage said there were some people who focused on desktop accessibility and others who worked on Slack for mobile, but they were scattered across the company. Panage joined Slack a few months ago as senior engineering manager and helped bring the company’s accessibility efforts under one roof. Before joining, she worked on accessibility efforts on iOS at Apple and held roles at Twitter before that.
Slack recently announced updates to improve keyboard navigation and introduced a new interface for screen readers as well as what the company called “an ongoing effort to bridge gaps.” Panage said bringing together one unified accessibility team has helped Slack focus on these different areas of improvement and work with teams across the company to build new features with accessibility in mind. But she stressed that the work is ongoing.
“Accessibility is never done,” she told Protocol. “A common challenge for companies is to say, ‘Oh, we made our product accessible. And now it's done.’ But it's not the case.”
This interview has been edited for clarity and brevity.
How is Slack’s approach to the topic different from others?
In large companies, in the Apples or the Microsofts and the big companies of the world, there's definitely an accessibility team. But I think it’s much less common in the small companies, and often there will be people who care deeply about it, and they might be scattered. They might start a networked effort across the company. I've seen that in various places as well, but it's not necessarily the standard for companies to have an accessibility team, a centralized hub of accessibility. That's one thing that Slack recognized pretty early as it started to grow … It's not super common, but it is super beneficial.
Can you point me to a time, either at Slack or a previous position, when you had an idea that didn’t work out in the way you expected? And on the flip side, what was a change you made that had an immediate impact?
Accessibility is a field that, especially when I started in it over 10 years ago, there was not a lot of information. There were standards online that I could read about there, but there was not much else. So I made a lot of mistakes early in my career. A common one I think folks will make as developers is to overlabel things or be overly verbose when you're thinking about screen-reader experience. So that was a mistake I made in many ways multiple times … We started getting this feedback from our screen-reader users saying, “Oh, hey, this is way too verbose. This is not helpful to me.” That was where I learned two lessons. One, verbosity is incredibly important for screen-reader users. Two, listening to our users is vital to making good decisions about the product, and certainly that's something that Slack was already doing before I arrived.
"[L]istening to our users is vital to making good decisions about the product."
As far as things that have gone really well, sometimes a very small idea can be a really big thing. One of the changes that we recently made in our updates at Slack was to add a couple preferences that allow users more fine-grained control over how their messages are read out. And it sounds so simple, right? It's like, “Oh, you read the date first or the date last.” It's the little preference, but this can be so important for someone using a screen reader because listening takes time. If the information I want is up front, you've just made me so much more efficient.
How did you decide to focus on these areas of improvement?
At Slack, we focus heavily on what our users tell us and the experiences that they're having. So this work stems from a large amount of time and feedback and process with both external user feedback that comes in through our various feedback systems as well as user groups who are full-time assistive technology users. By combining feedback from these two spots, we've found key pain points within the Slack product that we knew we wanted to really focus on.
And those were really focused around the notion of keyboard navigation and keyboard focus. We had a lot of feedback from our screen-reader users. And so we wanted to make sure we put a lot of work there to make sure the desktop product was fantastic for them.
Since joining Slack, what have been your top goals in terms of accessibility?
One of the things I've really wanted to focus on is thinking about how Slack can really take a stance in accessibility and build the product to be something that says, “This is how Slack should work from an accessibility standpoint. And this is how we believe — with the feedback of our users and with what we've learned in our research — this is what we want to create.”
The other thing is thinking about each platform individually. Just because there's a cohesive picture for accessibility doesn't mean it's going to behave exactly the same on each platform. It might need to be different. Android is different from iOS, which is different from web, etc. And so a second-tier focus there is then thinking about, “OK, so now we've agreed on how we want to approach it. What does that look like on Android? What does that look like on a web product?”
And then certainly as well, looking for any broken windows, any things where we're like, “Hey, this needs to be better.” So one thing that you may have noticed if you happen to use our Android product is significant improvements in our larger text size support.
What do you mean by your goal that you want to “take a stance” on accessibility?
We're thinking about Slack really as the digital headquarters right now. This is a place you go to get work done. Part of that stance is making sure that Slack is a place for everyone to come and to get their work done. And it's really about Slack being this digital headquarters that is equitable, that is delightful to us and that is efficient for all of our users.
And the other part of taking a stance on accessibility is about how we do accessibility. Not just that our product will be equitable, but also how do we actually approach making that happen? And the approach part of it is really strongly based, for us, in user-centered design and user-centered engineering. From both perspectives — from the design perspective and from the perspective of which we build the products — we want to be sure that we're drawing from our users and understanding what they're experiencing and what they experience in other products and on different platforms.
What does the process look like for introducing an accessibility improvement at Slack to implementing it?
We'll prototype an idea and we'll get something working, something functional, say, for example, a screen-reader feature. And so we'll get something prototyped and ready to share with our internal user groups who are full-time assistive technology users. And by doing that we can get that early information as to whether or not this idea was good or not … and there has to be a really big willingness to be wrong, because sometimes we don't get it right.
From there, we'll have a prototype, we’ll iterate with our internal user group and start to hone in on what the product is going to be. And then that will develop into a feature brief and something that becomes part of our road map for the accessibility team. From there, it's going to go through a pretty standard process of planning and execution all the way through. But through that planning and execution, we'll continue to iterate with our user group, so it won't just go into a box and come out the other side, but rather at various milestones, we will go back with them and say, “Hey, can you try this out? Give us feedback, take a pass at it.”
Would you say someone with an accessibility background should be in the room during every conversation about different Slack changes?
To some degree, yes. Obviously having accessibility in the room, in every meeting — we can't scale that. But when a feature is in the early phase — a great example would be something like the Huddles feature, where having someone say, “Hey, these are going to need captions" really early on — that's a really fantastic example of what happens when someone with an accessibility mindset is in that room really early.
What was your perspective as a user before joining Slack versus your experience since joining?
One of the things that drew me to Slack was noticing the progress they were making on accessibility. I'm always tinkering. I will make the text size way big, I will invert the colors on my phone, I will do all kinds of things just to see what happens, to learn about the product. And I was consistently noticing that Slack was making improvements. My friends who have visual impairments and my friends who are hard of hearing had made comments about some things they noticed and been impressed with the product. And so early on, I knew that Slack was a company that was really putting some great effort into accessibility, and that drew me there.
"[T]here has to be a really big willingness to be wrong, because sometimes we don't get it right.
Since coming in and joining, that perspective hasn't really changed. Now I just know the people who are doing this work. But since joining Slack, I noticed that the work was coming from a lot of different places. And so that was kind of what pulled me in. I thought, “Oh, it'd be so great if this were an accessibility team all under one roof working together,” because I think you can be more efficient that way. You can reach out through the company more successfully when you're coming from a centralized place. And it also helps people know who to go to when they have a question. So that was the shift I wanted to help Slack achieve by joining.
How has your background in psychology helped you in your role?
It's one of those degrees I did not anticipate I would utilize, and I found it very helpful in my career in technology and then specifically in accessibility. In studying psychology and doing a bit of psychology research through my undergrad, one of the things that I had to learn was a lot about thinking about how people think. And that particular skill … all of that became very, very useful then when I came to work in accessibility. “How could someone else experience this?” is the number one question we ask.
One of your goals at Slack is to identify “broken windows.” Are there any that you want to focus on in the coming year or so?
One that I'm very excited about is just seeing us improve our Android product and how it has its text sizes. I think that one of the challenges that the recent changes are trying to solve is around the fact that Slack is a web product on desktop. And so I think that because of that, I wouldn't necessarily say there's a lot of broken windows around it, but it creates challenges because it's a web product as a desktop app.
For a company that's scaling, how can you keep accessibility in mind?
It's a really big challenge. No question there. As a company grows, one thing that is important to establish pretty early on is what the accessibility process looks like … It's really important for something like accessibility in the same way we would process for security, right?
As a company is growing and adding teams, it's important to have a way that says, “This is how Slack does accessibility.” So as a new team spins up, that process is already there for them. They just need to look into it. They don't have to reinvent the wheel as to what these things mean. The process and the “how” is already there. In Slack’s case, that means the design reviews and the accessibility review toward the end, and the office hours.
