The Christina Xu Hypothesis: Accessibility is a Critical Aspect of Product Design

Christina is a product manager at Slack, focused primarily on improving the accessibility of both Slack and Quip (the collaboration tool, not the toothbrush company!) for people with disabilities.Previously to working in product, Christina was an ethnographer focused on how people incorporate technology into their lives, with over a decade of experience in observing and orchestrating social interactions on the internet and in offline subcultural spaces in China and the U.S.

In this episode of the Product Science Podcast, we cover how Christina’s team makes sure that accessibiilty needs at Slack are addressed and how we can help the industry do more for disabled users.

Subscribe for the full episode on Apple, Google Play, Spotify, Stitcher, YouTube and more. Love what you hear? Leave us a review, it means a lot.

Resource Links

Follow Christina on Twitter

Follow Christina on LinkedIn

Check out Slack’s Accessibility Features

Follow Holly on Twitter

Follow Holly on LinkedIn

Questions we explore in this episode

How does Christina convince other teams to start their accessibility work early in the design process?

• She uses an analogy of trying to put blueberries into a muffin after you've baked it.
• She says that top-down support like talking about accessibility and putting it in OKRs is critical.

What is her team's process for addressing accessibility needs?

• They check in with the team early in their process.
• They work with the team to identify what types of disabilities they need to focus on for different product areas.
• The Designer collaborates with the other teams to identify options that meet accessibility needs as well as meets product goals.
• As the product is shaping up, she does research on how accessible the user interface is.

How can we increase accessibility across the industry?

• Recognize that there is no one type of accessibility user. There are several different types of disabilities that we have to design for.
• Understand that accessibility benefits not only people living with permanent disability but also includes temporary and situational disabilities.
• We need to build awareness of disabilities and the capacity to empathize with these users.

Quotes from this episode

If you're baking blueberry muffins, you can't push blueberries into the muffin after they're baked. The earlier we have the conversations, the more easily we can steer the design decisions towards a direction that's easy to make accessible versus landing with a design that's great, but really difficult to make accessible, and now we have to make all kinds of compromises, and complicated remediation choices.

I think Silicon Valley tends to be a place where the workforce trends younger, trends more able-bodied, and I think that that means that we have to work extra hard to build the capacity for listening, and build the capacity for empathy towards a group of people who are actually not as far away from us as folks might think day-to-day.

I think especially PMs, we pride ourselves on knowing how the software is supposed to feel, or knowing how we're supposed to be able to make certain decisions. In the world of accessibility, if you're an able-bodied person, you don't have that lived experience.

The Product Science Podcast Season 5 is brought to you by Productboard

Check out their eBook: 10 Dysfunctions of Product Management

If your product team is struggling, it could be one of the 10 dysfunctions of product management. Learn more about each dysfunction and how a product management system can help you address and avoid them.

Get Your Copy

Transcription

Holly Hester-Reilly:Hi, and welcome to the Product Science Podcast, where we're helping startup founders and product leaders build high-growth products, teams, and companies through real conversations with people who have tried it and aren't afraid to share lessons learned from their failures along the way. I'm your host, Holly Hester-Reilly, founder and CEO of H2R Product Science. This week on the Product Science Podcast, I'm excited to share a conversation with Christina Xu. Christina, welcome.

Christina Xu:Thank you so much.

Holly Hester-Reilly:I'm so excited to have you here. I'd love to hear a bit about how you got to where you are today.

Christina Xu:Yeah, sure. It's been a winding path for sure. I, before becoming a product manager, used to be a researcher. I was an ethnographic researcher doing mostly freelance work, and mostly focused around helping companies really have a deep understanding of how their customers interact with technology and incorporate that into their real lives. I was doing a lot of deep exploratory research around a multitude of subjects. One was around China, and the tech infrastructure, and ecosystem there, actually. The other was just in the US with consumers around things like music, and entertainment, and social technologies.

Holly Hester-Reilly:Yeah, that's really cool. I am such a fan of research, so I love hearing of people who came into product that way. How did you get involved in research?

Christina Xu:Actually, I've worn so many hats over the years, but I think the common strand through all of it is that I've always been really fascinated by how people and technology interact. I wrote my undergraduate thesis on the history of instant messaging, so I guess a little bit, it was inevitable that I would end up in a research adjacent field. But I got into it actually, because a friend of mine was doing research at a time when I was in between jobs and needed someone to help out, and I had just always been so curious about it that I offered to help her out, and just really took to it from there, and kept looking for research gigs to build my skills. The way that I actually became a product manager eventually was that Quip, the collaboration tool, not the toothbrush company, I always have to clarify, Quip was looking for an independent researcher to do some exploratory research, and I ended up getting the gig, did a research project for them.It was super fun and they apparently enjoyed the results, because a few years later, they invited me to apply as a researcher. I applied for the role as a researcher and ended up getting hired as a product manager, which was pretty unusual. But Quip despite having been acquired by Salesforce for a few years at that point was still, I think, operating with a flexibility of a smaller company and startup, and they actually had lots of experience in onboarding product managers from folks with all kinds of different backgrounds, from content writing to customer success. It wasn't as unusual for them, and I was really lucky to be able to explore interests outside of my research path in that role.

Holly Hester-Reilly:Yeah. You mentioned that they had a lot of experience onboarding people from these other areas. What did that look like for you, when you joined? How did they bring you up to speed on being a product manager?

Christina Xu:Yeah, that's a great question. I spent the first few months really focused in the area that I knew best, which was doing research. I spent the first couple of months working with other product managers to set up research programs or research initiatives around things that they were curious about and in doing so, I think, learned a lot about how product team worked at the company, because I got to sit alongside these product leaders that were much more experienced than me, and watch how they were making decisions, how they were gathering inputs, and synthesizing it all together. I was also really lucky to have many incredible mentors at the company who spent time with me, and just checked in, and I was allowed to ask as many questions as I wanted, which as a researcher I was very experienced at doing so.I personally treated it as a research project of sorts. What is this culture of product managers, what are they doing all day, how do they make decisions? Eventually, was given a small project that stemmed from the findings of one of my research projects, which was really exciting for me. I had never, as a researcher, gotten to sit on the other side of the table in that way. I got to follow up a research finding with a small project that I planned, and went from there.

Holly Hester-Reilly:Mm-hmm. What was it like your first time working with the engineers and actually building the product?

Christina Xu:Yeah. It was a really amazing learning opportunity. I was working on a project that I... Going into it really felt like this is going to be quick, which is I think a lesson many product managers learn very quickly that there is no such thing as a quick, easy one. In the course of that project, uncovered a lot about how to work around previous technical decisions that may not be ideal for the current product, but you really have to maneuver around it. To me, the way that I thought about it was if you're a urban planner, or you're going to architecture or something like that, there's this vision that what you get to do in that role is play City. You have a blank canvas and you get to design whatever you want.In reality, if you're an urban planner, a lot of your job is trying to figure out how to make a four-way intersection 20% less bad. It was that kind of a project where it was like I went in with this grand vision of something that I thought would just be simple and snappy, and very quickly was confronted with the reality of working with previous existing decisions, especially technical decisions, and how to manure around that. I was very grateful for that learning opportunity. It comes in very handy every day, now that I work in accessibility.

Holly Hester-Reilly:Yeah. How did you get involved in accessibility?

Christina Xu:Yeah. As I was ramping up as a product manager at Quip, Quip started trying to stand up its first dedicated accessibility team, and they were looking for a PM who would want to take on growing that team, and building that team out. Accessibility is something that I had been interested in for years, but had never really directly interacted with. I became very interested in it, because I was friends with this incredible scholar, Sara Hendren, who has written a lot about design and disability. It was just something that was always in the back of my mind, just like if I'm given an opportunity to work on this, I absolutely will take it. When the call went out, I think I was probably the first one and maybe most enthusiastic person to put up their hand, so I ended up taking on the role.It was such an incredible learning opportunity. I was going in with very little experience in terms of accessibility. My team members, some of them have worked on accessibility at Quip before, but none of them would say that they were accessibility engineers or accessibility designers. We were all learning together for the first few months, and I have really taken to it. It's something that I ended up settling into. When Quip got merged into Slack, there was a role that opened up at Slack, the equivalent role, and I ended up taking that as well. Yeah. Really lucky to have found my way into it.

Holly Hester-Reilly:Yeah. How did Quip get merged into Slack?

Christina Xu:Oh. Quip got merged into Slack, because Quip was already part of Salesforce, and when Salesforce acquired Slack, there was some shopping around of companies. Quip and Slack have very similar cultures, very similar goals, and customer bases, and things like that, so it was a natural merger.

Holly Hester-Reilly:Oh, got it. Yeah. Now that you're a part of the Slack team, what does that team look like these days?

Christina Xu:Yeah. The Slack accessibility team is me, the product manager, there's couple of engineers both on the mobile side, and on the desktop side, and then we have dedicated designers as well on our team. The team has three different sets of responsibilities. One is that we actually build out Slack's own accessibility infrastructure, and accessibility-focused features. The most obvious one is the feature for adding alt text, or image descriptions, sometimes known as two images that are uploaded in Slack. We build out functionality for those features along with many other types of infrastructure that are really important for accessibility. We also are the first line of defense, when it comes to bugs that come in, that are reported by users that are accessibility related. Also, we spend enormous amount of time partnering with other teams all around Slack, all feature teams from across Slack to make sure that as they develop their new features and their new product areas, that accessibility is being kept in mind, and we work with them to make sure that that's the case.

Holly Hester-Reilly:Yeah. Tell me more about that, because I know it can be pretty difficult when you're in a position where you are a product manager that has to do a lot of work through other teams or partnered with other teams. What does that look like?

Christina Xu:Yeah, it's a great question. To say a little bit about, as an overview why this is so important for accessibility, it can be very complex. There are many, many different types of people with accessibility needs. Everything from people with visual disabilities such as full blindness or low vision, who may use assistive technology tools like screen readers, to users who are deaf and hard of hearing, who need captions and transcripts for any video or audio content that's being shared, to people who have neurodivergence. One example of an accessibility feature that many people don't think of, that is dark mode, actually, because dark mode can be more soothing, it can be easier to read, it can be less likely to trigger migraines for a large number of people. Accessibility takes on a great many forms and I certainly, as somebody who was onboarded into this relatively recently, it's an incredible amount of domain knowledge to learn. One of the biggest challenges that we have is that domain knowledge is very unevenly slit across the Slack organization.There's a tremendous amount of enthusiasm, and people at Slack are genuinely very invested in accessibility, but the knowledge of what that means, and how to actually build for accessibility really sits very heavily within my team. A lot of the work that we do when we're partnering with other teams is try to figure out how we can teach as we go, as well as how to help folks realize when the right moment to start thinking about accessibility is. One saying that we've been using that's really caught on is, if you're baking blueberry muffins, you can't push blueberries into the muffin after they're baked. For something like accessibility, where folks historically thought of it as something akin to compliance, or legal, security stuff, like stuff that maybe you'd want to wait until the very end, because you know it's going to be a hassle, and you don't want to have it derail any of your plans early on. A lot of our work has been going around to the different teams, and helping them understand that actually this is a conversation you want to start having early.Because the earlier we have the conversations, the more easily we can steer the design decisions towards a direction that's easy to make accessible versus landing with a design that's great, but really difficult to make accessible, and now we have to make all kinds of compromises, and complicated remediation choices.

Holly Hester-Reilly:Mm-hmm. How do people respond to that?

Christina Xu:I think that in general, at Slack, it has been people are very enthusiastic. I think people understand the mission. One thing that I think is so critical for getting accessibility right at organizations is top-down buy-in. Our leadership have been very, very helpful in being very public, and visible about the importance of accessibility to our organization. There's been OKRs and things like that, that directly reference accessibility, that call it out, and I think that that sends the message to the rest of the organization that this is something that's important. I have definitely seen, I think, in other organizations, oftentimes, accessibility efforts start with one person who really cares about it, and they're pushing for it, and advocating for it internally, but if there isn't that org-wide buy-in, it can be something that gets seen as this is just going to... Why to invest the time to do this, alongside all the other things we already have to be doing? I'm grateful that our leadership has really pushed back against that messaging, and made it clear that this is important to us.

Holly Hester-Reilly:Yeah. How long does the process take, when you're working with a team outside of your own to help them implement these things?

Christina Xu:Yeah, great question. It's a process that can take, ideally, as long as it takes for them to develop the feature. Obviously, we're not hands-on that entire time, but in the course of a feature development, if I had to dream up how this process could work, we're checking in with the team very early on as they're starting to collect inputs around what the requirements for this product are. We're telling them, hey, you need to pay special attention to these types of users, because one thing that is a personal pet peeve is, I often hear the phrase accessibility user and it's like, there is no such thing as an accessibility user. We have people with disabilities, and people with a wide range of disabilities. What a person who has a visual disability needs is very, very different from what somebody with neurodivergence, and what they might need.Even within the umbrella of neurodivergence, there's so much variety. I work with them to try to identify these are the types of users that we want to pay special attention to throughout the development of this product. For example, if it's going to be an audio-visual feature, then we want to be thinking about things like captions. If it's a feature that has very complicated net new interfaces components, then we really want to be thinking about how do we make this interface legible to people who are blind, and can't see the interface, and need to interact with it purely through a screen reader. We do it a little check in there. Ideally, folks are research involved, and they're gathering inputs from those user groups even when they're doing research. Then as the product definition gets defined, we're working together to say, all right, this is the bar, these are the things that need to be true for users with disabilities.They need to be able to do all of these tasks, and getting as specific about that as possible. And then throughout the design process, our designer on our team is really amazing at embedding with other teams, and basically helping other designers review their work, and pointing out places where we may need to slightly tweak the designs to make it more accessible, becomes a dialogue. It's not like somebody brings a design to our team and we're like yes or no, and we move on from there. It's a conversation about, all right, I think this could be made more accessible if we do X, Y, or Z. Then they go back and say, well, X and Z aren't really on the table, so let's try Y, and we go from there. As the product solidifies, we start using a variety of different ways to try to get feedback, which is really, really important to us.At Slack, we have at least three different ways of doing this. One is we work with these really amazing accessibility consultants at Prime Access Consulting. We have weekly office hours with them, and they specifically specialize in the screen reader experience, which for many folks is the most challenging part of accessibility. It's a way of using a computer that is the most foreign to the average person working at Slack, I would say. We take the designs to them, walk them through it by just verbally describing it, and then they provide a wealth of feedback about, I would find this very confusing, or we can tweak this, or technologically speaking, we should do this or not this, and that's immensely helpful. We also have a partnership with a third-party vendor called Fable, who specialize in finding people who use assistive technologies, and doing user testing with them. That's another great way of getting feedback. Finally, we have a accessibility champions group who are real Slack users, who have agreed to pilot test features. Sometimes, we'll release features early to them, and get a wealth of feedback that way too.

Holly Hester-Reilly:That's interesting, because I was actually going to ask you how you recruit people in this demographic. Are there other ways? Is it something that you typically have good data about for the whole user base?

Christina Xu:Yeah. In terms of recruiting, by and large, this group of users tends to be disproportionately vocal. It's partially because they have to be. Unfortunately, the industry bar for accessibility is not where I would want it to be in 2022. There's a lot of challenges, and I think the baseline default is that many of the tools people are using every day are not necessarily being built with accessibility in mind. For folks who are disabled and who are in the workforce, they have already overcome so many different barriers that they shouldn't have to overcome, that they're self-selected into a group of being people who are not shy at all about feedback. We basically hear a lot from users who have various different types of disabilities about feature requests, bug reports, things like that, and we'd reach out to them and basically say, hey, you've provided a lot of great feedback, would you like to join the group?

Holly Hester-Reilly:Mm-hmm. Got it. Yeah. I think that's a common way of recruiting people as well as keeping that conversation going when people are providing feedback and speaking up. What are some of the things that you wish more product managers cared about, when it comes to accessibility? How do we spread the word more throughout the community as a whole, especially for people who are maybe at a company that doesn't have that strong leadership voice on it that you see at Slack?

Christina Xu:Yeah. A couple of things that I wish more people knew about. First is the point I just made about there not being one type of accessibility user, and real understanding that these are many different user segments that just want a customized experience that work for them, or an experience that plays well with their tools. It's important to understand the breadth of that, and understand specifically which parts of that user base you're trying to make sure have a smooth experience at any given point. Another thing I think is just the prevalence of disability. Somewhere between, depending on how you count, 15% and 25% of the world's population lives with some sort of disability. That's an enormous number. Even beyond that, accessibility benefits not just people who are living with disability, but also people with temporal disabilities. Imagine you break your arm for a couple of weeks or something like that, or as happened to me earlier this year, your keyboard gets some gunk stuck in it, and now suddenly, a couple of your keys don't work, right?That's a form of not being able to use computers through the normal input devices that are expected, and also situational disability. Imagine you're cooking and you need to swipe something on your phone. It's obviously not the same thing, but all of those situations benefit from accessibility. I think Silicon Valley tends to be a place where the workforce trends younger, trends more able-bodied, and I think that that means that we have to work extra hard to build the capacity for listening, and build the capacity for empathy towards a group of people who are actually not as far away from us as folks might think day-to-day. That, I think, is really important to understand. But in terms of actual product design, I think a couple of very key things to understand are, one, just start early, start as early as possible, really try to start thinking about it from the beginning.One really easy way to start being more conscientious around accessibility, and to be able to test things yourself, and build everything yourself is to just try using whatever feature you're building with just a keyboard. The keyboard only experience is a foundational layer of accessibility, because there are lots and lots of other assistive technologies that rely on that interface, so just navigating around with a tab key, and enter, and arrow keys, things like that. If you're not able to navigate to every single part of the feature you're building in that way, or if the interface doesn't make sense using only that navigational paradigm, then there may be places where accessibility is going to be very challenging to tackle later on. The earlier you think about those things, the better. And then the other point is just that, one of the most valuable lessons I've learned doing this work is the realization that intuition is earned, and it's earned slowly.I say that, because for a lot of people in the tech industry, and I think especially PMs, we pride ourselves on knowing how the software is supposed to feel, or knowing how we're supposed to be able to make certain decisions. In the world of accessibility, if you're an able-bodied person, you don't have that lived experience. I have 20 plus years of spending way too much time on a computer every day that informs my intuition around how software product is supposed to look, and how I'm supposed to interact with it using a mouse. I don't have 20 plus years of experience using a screen reader, or using voice control and dictation, or any of these other assistive technology tools.In that situation, I think it's so important for us to try to be as humble as possible, and that means taking the time to check in with our users, with people who are giving us real, live feedback as often as possible. There are so many situations in which I thought, surely based on the last five things I've learned, the sixth thing is I know how to make this decision only to find out that's absolutely not the case, and that there's something I totally failed to consider.

Holly Hester-Reilly:Yeah. I think we all learned that lesson several times throughout careers in product.

Christina Xu:Definitely.

Holly Hester-Reilly:Yeah. One of the things that I was thinking about as you were saying that about how early you should start is, what is your perspective on when early stage startups should be caring about accessibility?

Christina Xu:That's a great question. Definitely, in the industry, you rarely see companies making an effort around accessibility until they're about probably after the stage at which they are having dedicated research roles. Obviously, I think personally that people should think about accessibility as quickly as possible, and here is my pitch for why. Even though it is something that is very resource-intensive, and not necessarily something that's top of mind when you're trying to get out to market, I think there are so many really interesting side benefits of paying attention to accessibility. One example I'll give is just that, when I'm doing work on accessibility and just testing a feature for accessibility, for example, the number of issues, and bugs, and weird product behaviors I find that no one has caught, so can be really surprisingly enormous. You find all of these dusty corners of the product that don't quite 100% make sense, or like somebody put a button there and forgot about it. There are just lots of different types of detail-oriented work that accessibility is really compatible with, because you can think of certain types of users with accessibility needs.I think in screen reader users are especially good example. They're interacting with your interface very literally, and very linearly. They are going through every single button, every single piece of text on your page and so, if you have something that is out of place, or if you smush some buttons into a toolbar somewhere, but they don't really make sense together, that is actually the user group that's going to be the most sensitive to that. When you're going through and testing, you also naturally are forced to think about, is this actually the most efficient design? Is this the design that actually makes the most sense? So many times, things that I uncover and flag as this is going to be really hard for a screen reader user to understand, also tend to be the things that are hard for new users, in general, to your product to understand for people who are not as experienced with that class of software products to understand, and so on, and so forth.There's a lot of, I think, auxiliary benefits that you get from paying attention to accessibility. Also, the other thing I'll say is that, if you do as an early stage startup, want to eventually be selling to enterprise customers, or selling government clients, selling to educational clients, all of those customers are people who are going to care a lot about accessibility at some point. The earlier you start, the less you have to suddenly realize that you have years of accessibility debt to tackle, and try to figure out how to completely refactor your whole product without making it look on the surface any different to the users who have gotten used to the interface.

Holly Hester-Reilly:Yeah, that's fair. When an early stage startup does invest in this work, who do you think they should be tapping to help them figure out how to do it?

Christina Xu:Yeah. Do you mean in terms of who internally, like what are the right roles to start?

Holly Hester-Reilly:Yeah. What are the right roles? Are there the right roles typically in an early stage startup, or do they need outside help?

Christina Xu:Yeah. I think a little bit of both. I think that what you definitely need is somebody on your team who has at least a bit of natural enthusiasm, and curiosity around this topic. Again, it doesn't have to be someone with 10 years of experience doing this, although it's obviously great to have if you luck into it, but somebody who's just actually genuinely has an interest in doing accessibility work, and is willing to take the time to learn, giving them the space to do that learning on their own, and seeing what can come up with is really powerful. At the same time, for me, certainly when I was in the learning process, having outside help from folks who, again, are living the experience, have been working in it for a long time is so helpful. I will say that in my first maybe three months as a product manager working on accessibility, which was before we started getting outside help, about a year later, I looked back at all the decisions I made in the first three months, and every single one of them was flawed in some way.They were all directionally correct and had the right intention behind them, but there was just so much I didn't know. Joining at least some online community, or taking the time to listen to podcasts, read articles, things like that by people who have been working in this space can make a really, really big difference. Yeah. Again, I think, as with all parts of product research, the faster you can talk to real users who are using your product, and are having specific problems, or getting your product out in front of users and saying, does this make sense to you, can you even use it? It can be a very bracing conversation, but I think it's so important to have that early, because I think it really drives home for folks the importance of this work, but also points out things that on your own being new to the base, you may not be able to catch.

Holly Hester-Reilly:Mm-hmm. Yeah, that makes sense. Switching gears a little bit, I'm curious at this point, how do you see your future in product? Do you want to stick with accessibility for a long time, where do you go from here?

Christina Xu:Yeah. It's a great question. I would love to stick with accessibility. I think it's such a fascinating space. It's a really fun set of problems for a specific group of people that I happen to be in. I grew up as an immigrant in the US, and I spent a lot of my early years translating, translating for my parents, translating things for myself and for me, accessibility, there's something really nice about the act of trying to translate and interface that, I love, and are using all the time, for someone who experienced it in a very different way. I feel really drawn to the work, and I would be happy to keep doing it. It is something where I think, over time, as you get to know it better, the more creativity, I think it can be part of work. I think a lot of people, if they've only had tangential experiences with accessibility, think of it as mainly something that is compliance-based. Your customers come back to you and say, hey, we did an audit, and you need to fix these 15 issues, or whatever it is.I think that makes it seem like something that's very rigid. The longer I've spent working accessibility, the more I realize that's not the case. Not only are you dealing with such an astonishing variation of preferences, and people's setups, and just what they're creating for themselves to be able to access the internet, but also there's so much nuance in how you communicate the goal of an interface. How do you make an interface user-friendly in a different paradigm, or how do you make it fun? How do you make it delightful to use? How do you make it efficient to use? There are all these decisions that have to be made, so definitely never a dull moment.

Holly Hester-Reilly:Mm-hmm. Yeah, that's awesome. Well, are there other things from your career in product that you wish that more people knew about?

Christina Xu:I also want to mention two general buckets of things that I think are important lessons for product managers thinking about accessibility. Both of them root in this idea of metrics. As a group of people, product managers spend a lot of time thinking about metrics, and how to measure success. One question that I get all the time is, basically, how do we measure the impact of accessibility? That's something that's a very complicated question, when it comes to accessibility. You asked earlier about whether we have good data into our user base, and the truth of the matter is that we don't, and we don't for very specific reasons. Basically, unlike collecting information about somebody's browser they're using or something like that, we do sometimes have the technological means to understand whether somebody has assisted technology turned on, and whether they're using our app with that technology, we choose not to collect that data, and that's for multiple purposes.One is that it is potentially sensitive data, because it reveals potentially a user's medical information, or you can at least imply somebody's medical information. We don't collect it. Another reason is that it, to us, is a privacy concern. Everyone is entitled to use the internet using whatever combination of tools they want, and we shouldn't necessarily have an eye into that, to be able to then potentially make choices like serving you a different experience based on the fact that you have different assistive technology turned on. But another point is that, a lot of times, when people are asking about metrics and accessibility, what they really mean, even if they're being well intentioned about it is, does it really matter in the grand scheme of things, right? If only five people are going to be using our app or whatever it is, with screen readers, or with whatever assistive technology we're debating, is it worth it for us to take the time out of our development cycle to really invest in that experience?Because again, as a discipline, product cares so much about metric and about serving the greatest number of users. To that, I'll say one thing that I've really experienced, especially when I started doing accessibility at Quip, it was one of those situations where we had an enormous amount of accessibility that we were trying to burn down. What I really experienced as the impact of that is that accessibility is something that is reverse viral, is how I think about it. What happens is, if somebody can't use your product because of accessibility barriers, they are going to tell their team, hey, I can't use this tool that you asked us to use. Their team, if they're good people and they respect their colleague, which I hope they are, are going to be like, "Yeah, that's terrible. We're not going to use this tool anymore." What's going to happen is, that's going to spread.Looking at the percentage of your users who have some disability, and are going to be impacted by accessibility issues is the wrong way of thinking about the question. The right way of thinking about the question, especially for tools like Slack where we are aspiring to be the digital HQ that connects everybody at work, we need to be thinking about it in terms of how many teams are impacted by this issue. That answer is almost every team at companies of a large enough scale, because that ripple effect of one person even not being able to use it, that's going to ripple out to their team, and then the department, and their business unit, and so on, and so forth.

Holly Hester-Reilly:Yeah. That makes a lot of sense, and isn't something that I'd necessarily thought about myself. It's a good perspective to have. What should people do if they're interested in getting involved in accessibility themselves? Say there's a product manager who's listening to this and they're like, "Yeah, I wish I was involved in that area." How do they get started?

Christina Xu:One, just start learning about it. There are lots of great talks online, blog posts. There's a great little weekly newsletter called Accessibility Weekly that I follow. It's just a collection of little bite-sized blog posts, and talks, and things like that, that I find really helpful. There's actually a web accessibility practitioners Slack workspace that folks can join if they're interested, and it's just a place where people are posting questions about accessibility, and helping each other out as part of the community, which is really, really great. I plugged her work earlier, but Sara Hendren is, again, amazing scholar, and has written this book called What Can a Body Do, and I cannot recommend it enough.It's actually not about web accessibility at all, but it's just about disability, and design. It will absolutely transform the way that you think about disability in general, or give you a framework for thinking about that, if you haven't been yet. I think just starting with curiosity, learning how to do some basic accessibility testing, such as learning how to use the screen readers that are built into your phone and your laptop, trying to do all the things that you would do in a normal day using just your keyboard, not touching your mouse, and seeing how that goes. All of those things, I think, are really great ways to start learning.

Holly Hester-Reilly:That's awesome. All right. Well, this has been a really interesting conversation, and I really appreciate you taking the time to share with us what your journey has been like, and how you improve accessibility at Slack.

Christina Xu:Thank you so much, Holly.

Holly Hester-Reilly:Thanks, Christina. The Product Science Podcast is brought to you by H2R Product Science. We teach startup founders, and products leaders how to use the product science method to discover the strongest product opportunities, and lay the foundations for high-growth products, teams, and businesses. Learn more at h2rproductscience.com. Enjoying this episode? Don't forget to subscribe, so you don't miss next week's episode. I also encourage you to visit us at productsciencepodcast.com, to sign up for more information and resources from me, and our guests. If you liked the show, a rating and review would be greatly appreciated. Thank you.

‍