00:00 Hey everybody, this is Kent and I'm joined by my friend Shruti Kapoor. How are you doing Shruti? I'm doing well Kent. Thank you for having me here. I'm so happy to have you here. You're just a lovely person and I love chatting with you and I love all the cool things that you do. I would love for our audience to get to know

00:19 you a little bit as well. So could you give us an intro to yourself? Yes. First of all, you're really cool too and I love you. You're awesome. You're an amazing person. So thank you for having me. Mutual feelings. Hi everyone. My name is Shruti

00:35 Kapoor. I am a front-end engineer at Slack. I do accessibility at Slack. I do a lot of front-end stuff. You might have seen me talk about React. I'll make my YouTube videos where I also talk about React.

00:51 Yeah. Awesome. Thank you. When you mentioned your work at Slack, it reminded me that you actually have a patent pending with some of the work that you've done at Slack. Do you want to talk about that really quick?

01:06 Yeah. So I'm very happy that I have this patent in my name or will be in my name. But this is actually a patent which solves the problem of infinity mirroring, which for those who may not know what that is, I'll explain briefly. When you try to share your screen and if

01:24 you're sharing the screen where you're looking at. So if you share that screen, you'll see another screen and then you'll see another screen and you'll see another screen. So it's kind of like this infinite mirroring of your current screen. That's what infinite mirroring is. So my patent actually solves this problem. And I encountered this problem

01:43 when I was building a clip feature for Slack. I don't know if most people would have used Slack or use clips, but it's basically a feature by which you can record like a 30 second video of yourself just talking or screen sharing or whatever. So we call it like it's

01:59 basically like a video recording feature. We call it clips. And while I was building this, I found out this problem and we thought about how can we improve the user experience so they don't see this janky experience and figure out a way to solve this problem and patented it. Yeah, that is super cool. Congratulations on that. Very awesome.

02:18 Thank you. And Shruti, you and I have known each other for a long time. I don't think that we knew each other before we each were at PayPal. I can't remember how we were first introduced,

02:33 but it's definitely been like five years or so that I've been following you on social and just keeping up with what you're doing. So it's been just a pleasure to get to know you overall this time. Yeah, I think I know how I got introduced to you, which is when I was getting interviewed

02:52 for PayPal. My interviewer said, do you know Ken C. Dodds? And I was like, yeah, I know Ken C. Dodds. He's like, yeah, he works for PayPal. And that's one more plus to join PayPal. So I was like, okay, that's really cool. Okay. And then sadly, I left pretty soon after you started. But yeah, that was a good time.

03:12 I loved it there. That was a fantastic place to work. I had a good time, at least. Me too. Yeah. So your work at Slack is really focused on accessibility. You did that video stuff for a little bit, but now you've kind of shifted over to accessibility. Slack is built using

03:31 React, if I'm not mistaken. And so you've thought a lot about how to make accessible user interfaces with React. How did you end up in that position? Wasn't the video stuff cool enough? Or what caught your eye about accessibility?

03:47 Yeah. So actually, I stumbled upon it through accident. When I joined Slack, we were pushing out huddles at the time. And huddles, for those who don't know, is a video call feature of Slack.

04:03 So we were pushing huddles, and we were in that final mile where we were supposed to make sure that it was accessible. And I was given the task of making sure that the component is accessible, the feature is accessible, things like that. So as I was going through it, I noticed that

04:19 actually the way we had built it, it was very hard to put accessibility into it. So we were slapping accessibility as a last thought. And as I was going through this and testing it out, I figured out this was really hard to do. And the best thing would be to scrap this and build it

04:35 again. So I ended up having to scrap the component that we had and rebuild that component. So it was the grids component. So if you launch Slack, you'll notice that it kind of has a grid like what we're seeing right now. It has a person and a person, and there's other people as well.

04:51 So we call this the grid component. So I rebuilt that component. And while building that component, I figured, I learned how hard it was to do accessibility right, and how much better it would have been if we had thought about accessibility from the beginning itself.

05:05 And I had never kind of used or built accessible applications that thoughtfully before. It was always kind of like, oh, is it keyboard accessible? Okay, sure. If it is, then let's move on.

05:20 So it wasn't really like a serious thought ever. But when I was working on this grid component, I was working with the accessibility team at Slack, and I learned how difficult it is to do it

05:33 well and do it properly, and how much thought goes into it. And so I thought I want to learn more about this. As a front-end developer especially, I think this is a really nice skill to have, like learning how to build components who have accessibility built in. So I thought this is

05:49 something that I want to learn. And so I did the video project, which was really fun. And then I was looking for my next opportunity, my next project. And the accessibility team had kind of like this rotation where they invite people from different teams to do kind of like a trial semester, like trial quarter with them, just like work with the accessibility team, build a feature, see how you

06:09 like it. So I was like, this would be a really great opportunity to learn about accessibility. And so I did that for one quarter, and I built something which had accessibility from the get-go itself. And I was like, I think I want to do more of this. I want to take this seriously. I want to

06:25 do more of this. And so I joined the accessibility team full-time. Wow, that is so cool. I love what the accessibility team does to let people like do like a trial run or have that experience. That is super awesome. How big is the accessibility team? So there's four engineers. As of now, we have

06:45 one manager, and we have a product owner, and we have a designer. We have two designers, actually, so fairly big in size, like fairly decent in size. Yeah, yeah. Now, this is kind of interesting to me because at the start, you mentioned how you were trying to tack on accessibility after the fact,

07:02 and that doesn't work out very well. With an accessibility team, I imagine it would be very easy to fall into running around the product, finding accessibility bugs, and telling other teams that they now need to tack on accessibility features. You probably can't tell them, okay,

07:20 we've got to rebuild this. Maybe you can. I'm curious, how do you influence the Slack organization such that people are not tacking on accessibility features and actually building it from day one?

07:33 Yeah. So I think the really big way to implement this is to let the team members who are building it as the first step to know that accessibility will be a requirement. And really, the first step is to work with designers because those are the ones who are building out. We're speaking to

07:51 users, but also building out the first design that a front-end developer is going to be working on. So our first step is to educate the designers and let them know that the components that we're building, so we have a Slack kit, which is our design system team. So let them know that the design components, design system components, are built with accessibility in mind. So if you're

08:10 going to be building a new component or a new design, make sure that you're using the components that are already built, so the design system components. And then if there is anything that is new, a brand new component that doesn't exist, come to our office hours, showcase your design,

08:27 and talk to us about what the features are so we can advise you on what accessibility needs might be and if you've thought about certain things. So our approach is always to go from the first level of design or the first step of the product development, which is the designers itself.

08:44 And then we have our office hours, which is how we help developers and designers understand what the problems might be or if they've thought about certain things. It can be really hard, and it can be really hard to kind of scale the team because there's only four engineers and

08:58 there is only so much we can tackle. So we kind of act as advisors to the team, to the entire company really, and help them answer questions. So we are there for support and need and help. Yeah, so you probably spend a lot of time training then.

09:15 Yeah, I guess not training as much as knowledge sharing. So office hours is kind of a big thing then we also have like a help channel, which is how we kind of see who needs help. Not training as much, but more ad hoc help.

09:37 So do you end up contributing to the different parts of the product as well, or are you more like consulting and like reviewing PRs and stuff like that? Both actually. So it depends on the feature and depends on what the team's bandwidth is.

09:54 Our team and the team that's working on the product. So for example, when we launched the Slack redesign, I did work on the redesign as well. It was a big kind of product launch. So our entire team was working on the feature itself. There are some other products that I went out,

10:13 which our team was kind of an advisor. Most of the times our team is building the feature along with the folks, depending on like how big the feature is. For example, we had workspace feature, which went down, which is how you can like switch between your workspaces at the top.

10:30 And I built that as well. So it depends on the project really. But most of the times our team is building features for the other teams as well. Yep, that makes tons of sense. Cool. That's cool that you have this opportunity to just laser focus on something like accessibility and that

10:49 Slack at least is investing in that sort of a thing. It's a really awesome opportunity. What do you find are the things that the engineers you work with mess up most often? I think one of the big things that I have noticed is, and it's just true for any developer,

11:09 not just folks in Slack, is that accessibility is usually thought as like a last thing we want to work on. We have the designs, we have our deadlines, and we are only focused on getting the product out, but we don't really think about making it accessible. And then the second thing

11:27 is we don't really know what it means to make it accessible. What do you need to do? Do you need to add audio roles? Do you need to test something? Are there any plugins? So I think there is a general kind of lack of knowledge in accessibility. And one good thing about

11:42 accessibility is if you think about it from the beginning itself, it becomes a lot easier to build a good product and feature that's accessible from the get-go. So one of my biggest kind of advice for folks have been, think about what you're building and

11:57 think about how users who are not using a mouse are going to use it. Because there's going to be people who are going to navigate your app with just keyboard. There's going to be people who don't even use keyboard or mouse. They're going to just be using a screen reader. How are

12:13 they going to navigate? So in addition, I think one thing that most people do know is contrast, which is great, like text contrast, which is great. So in addition to what the site looks like visually, how are people going to interact with it? And just building a little bit of empathy

12:28 for people who are using websites other than just the mouse is going to be really helpful in making your app accessible. And so, yeah, I'll pause there. Yeah, yeah. So you're not finding people struggling to label things incorrectly anymore.

12:45 Like that seemed to used to be a big issue is that people weren't labeling their inputs anymore. But I personally haven't seen a lot of people make that mistake anymore recently myself. And it's interesting that color contrast hasn't been something that you have seen much.

13:03 That's probably what I noticed most, but it's probably because that's the only thing that actually really affects me, to be honest, as a fully able-bodied person. But yeah, so that is, I like that you seem to focus on the mindset and the empathy that's required because it really,

13:24 uh, accessibility kind of gets into everything that we're doing when we're building web applications. Yeah. And, you know, empathy is so important because when we think about folks who need accessibility, we often think about people with disabilities. But one thing we forget

13:39 is that even people, able-bodied people like us also benefit from accessible applications. And also accessibility is not something that is just helpful when somebody with disabilities is using. It can also be helpful for people who may have temporary disabilities. For example,

13:56 you're in an accident and you hurt your arm and you can't move it. And maybe just like your primary hand, like left or right is not working. So you need to use your other hand. So it's also about those things. Like when you build an accessible application, you're not just helping people with disabilities. You're also helping people who may have temporary disabilities. Another thing is that

14:17 a lot of our parents are getting old. And so having like big font sizes or the ability to zoom in also really help people who are aging and may not be able to see as well as they used to. Even though they are completely able-bodied, it's still like accessible needs are also

14:32 changing over time. Yeah, that makes sense. Well, probably there are some engineers, I expect, who don't know anything about accessibility and others who do, but they just find themselves busy. And I think that all of us will be a lot more motivated to make

14:50 accessible UIs when we get older and we can't see as well and everything too. Yeah, that's kind of interesting to think about. So let's talk about React and accessibility. Is there anything

15:06 like any common pitfalls for developers when it comes to building React-based applications that you need to watch out for? I think one of the common pitfalls is using attributes incorrectly.

15:22 And I've seen this because I have made this mistake as well. So for example, let's say because in React you have the camel case. You have the camel case class names, right? So

15:37 if you're writing an attribute, for example, data ID, you would have data and then ID would be capital. But with accessibility, the labels or the attributes are supposed to be hyphenated. Or kebab case, yeah. Kebab case, yes. So that's actually one common

15:57 mistake that a lot of developers make, which is let's say you need to write ARIA role. Instead of writing R capital of ARIA role, it needs to be hyphenated. So it shouldn't be camel case, it should be hyphenated. Very simple to fix, but often a mistake that I've seen in applications.

16:15 Yeah. I wonder also, can you talk a little bit about misusing ARIA attributes and things like that? There's a common saying that the first rule of ARIA is don't use ARIA.

16:31 Yeah. It's so funny, isn't it? And the reason that rule is because if you're using the semantic HTML elements, you don't need to add ARIA roles. And this is why semantic HTMLs are recommended. Because if you're using semantic elements, for example, button, as opposed to div,

16:49 that role is built in within button. And so in that case, you don't need to add button role equals button because button already has a semantic role of button. And this is why semantic HTML is better than using div with a role of button. So that is actually a very common mistake that

17:05 folks make, which is adding roles or attributes that you don't need somewhere. Another common one which happens with buttons also is attaching labels. So for example, adding an ARIA label to a button. But because it's semantic HTML, the button's label automatically comes from the label

17:22 that you're adding to the button. So you don't need an ARIA attribute. So you're right. The first rule of ARIA attributes is to not use ARIA attributes. Yeah. In fact, it can mess up the screen readers in interesting ways too. And so you're wasting

17:42 effort if you do it incorrectly. It's kind of interesting how that all comes to be. In testing library, I worried. So testing library is, for those who don't know, it's a library that

17:57 I wrote for testing applications that are based on the DOM. And there are a bunch of queries, and one of them is to query by role. And one of the worries that I had with that was that people would start adding a role to something just so they could select it,

18:15 like adding a role of button on a button when that's an implied role. I haven't really seen that too much, but it is always in the back of my mind that people are overusing these attributes and misusing these attributes in some cases. So something to be aware of for sure.

18:35 Yeah. So Shruti, if somebody wanted to start getting more involved in accessibility, maybe they have a friend who struggles with a disability and it just is a real pain for them to use the internet. And what would be the best

18:51 way for them to start learning about it and developing some of that empathy that you need for accessibility? Yeah. So I think the official

19:03 documents that accessibility, I think it's called the W3C. I don't know how to say it. The WCAG? The WCAG are the guidelines, which is written by the W3C consortium. Is it a consortium

19:22 committee? I don't know. Something like that. Something like that. They actually have really good documentation, not just on the technical implications, the technical specifications, but also on building empathy, which I love

19:37 because they have a whole list of users who have needs for accessibility and we use assistive technologies. So it is a really great primer on getting started with accessibility and just knowing who are the people you are impacting. So I love that resource. W3C, great resource for

19:56 starting. The WCAG guidelines, which is set as a benchmark for accessibility requirements. Those are the things you need to follow to make sure that your site is accessible. Those are great. However, I think one of the best resources for accessibility is on MDN.

20:14 Really great way to explain it. Really great resources and examples as well. So those two are kind of like my main. Then there is a really great newsletter. I'm going to have to find the link and send it to you, which actually sends articles on Accessibility Weekly. It's called

20:33 Accessibility Weekly, I believe. I think that's the name. Also a really great resource for learning how to build components accessibly. Every week there's a new component, new use case. It's a really great newsletter if you want to be involved in the community and learn on accessibility.

20:52 Yes, it's A11yweekly.com. A11y is the shortened accessibility thing there. Yeah, that's great. I typically go to WCAG or WCAG or whatever myself occasionally. I actually never really

21:10 considered going to MDN for accessibility tips. That's a good tip there. So do you have any libraries that you recommend people use that will help them build accessible React apps? So actually, do you mean like component libraries or do you mean...

21:32 I don't actually have a component library in my mind. I guess you have your own over there at Slack. Do you have a team that I guess is dedicated to that and you are kind of advisor over there to help them make it accessible? Yeah, that's us. Yeah. Oh, right. Yeah. Yes. So at Slack,

21:50 we have our own library, own set of tools, own set of components that are accessible. So we advise using that. Yes. There's a really great tool which I recommend, which is Axe Tools. It's an automated testing tool. It goes to your site and figures out where some of the semantic problems might be. And it's really great because it will actually test against

22:09 the WCAG guidelines as well. So really great starting point. However, it's a guideline. It's not like a final word. So use it as a guideline, but don't completely lose yourself on it. One thing that I would definitely recommend is going through your site, like I was talking about, without a mouse and just doing a keyboard testing.

22:30 So the WCAG guidelines have a few different requirements for keyboard testing. And actually, I'm working on this article on Epic Web, so this is going to be a great resource. So there are a few requirements that you need to make sure that your site is following. I'll talk about one of them, which is making sure that every component is accessible through

22:51 keyboard, which means basically what you should do is go through your site and use your tab key to interact through all of the elements. And you want to make sure that you're able to read and interact with everything that's on the page. And one thing that you should also make sure is that when you're looking at the site, there's a certain visual order you have in mind, right?

23:09 And your site and the navigation that you're using with your keyboard is following the same order as a visual representation. So you're taking the user in a logical order. So those are two things I would definitely recommend with keyboard testing. In addition to keyboard testing, I also recommend folks do a screen reader test.

23:26 And every computer comes with screen reader. If you're using a Mac, it's voiceover. In Windows, what is the screen in Windows? It's NVDA. There's JAWS available, NVDA available. So both of those are great screen readers. So do a quick test of your site with screen reader as

23:44 well. Go from the top to bottom. Make sure that all of the words are being announced and it's not being announced multiple times. So those are the two high priority things that I would recommend if you're building a site, testing with the keyboard and testing with the screen reader.

24:01 Yeah, that makes lots of sense. And I wonder if you've noticed this as well, or maybe it's gotten better since the last I tried, but it seemed that screen readers, there is technically like a standard for this, but they seem to implement the standard differently. Has that been a challenge that you've faced?

24:20 It has been a challenge. And there has been sometimes issues that exist with one screen and not the other. And so oftentimes our life is about, oh, is it a screen reader only issue or is it an actual component issue? And so when that happens, we need to log an issue with the screen reader or fix it for the screen reader. It's been a pain. Sometimes it's a pain.

24:40 Yeah. Actually, I think of one in particular, there is an ARIA error message. Clearly, it's supposed to be for error messages, but apparently that is not generally used properly

24:58 by screen readers. And so in my stuff, I'm still using ARIA described by to do error messages. So yeah, it's tricky. This stuff is not easy. And it definitely requires a little bit of thought and intent behind people, but there are actual people who... What's interesting

25:18 about accessibility is the people who benefit from your work in accessibility the most, those people go throughout their day every day experiencing inaccessible experiences. And it

25:34 just is like nails on a chalkboard everywhere they go. And so some people will say, well, there's not a ton of people that their lives are going to improve by this. First of all, that's very flawed because improving accessibility is going to make it better for everybody. But

25:55 also those few people that you're talking about are also... Well, they're not as few as you think, but they also are just going through life with nails on a chalkboard all the time. That stinks. So I think that let's make it really good for them, please.

26:14 Yeah. We think about people who need accessibility as few people. I was looking at the stats. It's one in four people have accessibility needs, which is a crazy number. And when you think about it,

26:29 you're so right. People are going through these really bad experiences. And when they come across a site which is so much better than their competitor, that is the site they're going to use. So this way you're also bringing in a lot more people if you make your site easy and accessible to use. And one more thing, I think you had asked this question earlier, is why did

26:48 you get involved in accessibility? I feel like for once, I feel like my technical skills are being used to actually help somebody's life, actually help somebody's day-to-day life. So building with accessibility in mind is not just like a nice-to-have. You're also really impacting

27:05 somebody's day-to-day life and the way they move through websites just every day, which I feel is such a big impact you can make into somebody's life. Mm-hmm. I love that. Love that very much, Shruti. Thank you so much for giving us some of your time today. Is there a really good way for

27:22 folks to keep up with you and what you're up to? Yes. You can find me anywhere on the internet using my handle, shrutikapoor08. I'm on Twitter at shrutikapoor08. I'm also making accessible content on Epic Web, which I'm super excited about. And I also have a YouTube channel,

27:37 also shrutikapoor08. What is the 08? That is my birth date. Oh, I see. Okay, very good. 8th December. Okay, yeah, yeah, good. Well, awesome. Shruti, it's always just so lovely to chat with you. I'm looking forward to seeing you hopefully at React India later on in a couple months. It's going to

27:57 be awesome. Yes. And wherever else we run into each other. Maybe, hopefully, Epic Web conference next year. That'll be really great. That would be awesome. So thank you, Shruti, and thanks everybody for watching. This has been a good time, and we'll see you all next time. Bye.