Kent C. Dodds (00:00):
Hello, friends, this is your friend, Kent C. Dodds, and I am super excited to be joined by my friend, Sandrina, and I didn't ask how to pronounce your last name. Is it Pererria or Perrera?

Sandrina Pereora (00:10):
Okay. I'll give it one more shot.

Kent C. Dodds (00:13):
Okay, so it's Perer... Pererrea.

Sandrina Pereora (00:16):
Oh, no. Sandrina Pereora.

Kent C. Dodds (00:19):
Pereora. Yeah, okay. I'm sorry, I do try to say people's last... Or names, correctly, and I'm not always good at that. So, anyway, I'm super excited to have you on. Thank you for coming. So, Sandrina and I met... You know what? I feel like we had some interactions on Twitter, but my latest memory, or my oldest memory of interacting with you was through the KCD Discord, when you started doing meetups that were accessibility focused. And am I wrong there? Did?... We've talked on Twitter before though, I think.

Sandrina Pereora (00:57):
Yes, we did. I think the first time we were in the same room together was in one of your workshops, React Performance. Yeah. I signed up for one of those. So, I think that was the first time, a long time ago.

Kent C. Dodds (01:10):
Yeah. You seem super familiar to me when you started interacting on the KCD community on Discord. And so... Yeah. But it was such a pleasure to see you start using the meetups feature and not a whole lot of people do that. And it takes a little bit of bravery, especially, for what you do for the meetups is actually giving presentations, which is really cool. And I'd love to talk about that a little bit more, but I don't want to get too far into that before we get to know who you are. So, could you introduce yourself to our friends?

Sandrina Pereora (01:44):
Yeah, so my name is Sandrina. I live in Portugal. Portugal is a small country. We like tasteful food, amazing weather. If you one day, you want to visit Portugal, I'll be here, around.

Kent C. Dodds (01:57):
Awesome.

Sandrina Pereora (02:00):
I'm a front-end engineer for six years now. I think the place where I learned the most and I grow the most as an engineer was at Farfetch. It's a international company where I learned a lot about React, large codebases, design systems, accessibility as well. And, yeah. Right now I'm a lead front-end engineer at Remote, working remotely, living the good life. Besides that, one of the things I like the most there is that it gives me the freedom to share with the community, sharing stuff about accessibility or CSS, or anything. Yeah, that's me, very briefly.

Kent C. Dodds (02:42):
That's great. I guess that's one thing that the rest of us love about your company too, is that you're able to share so much good stuff. So, Sandrina, you have given, I think, three presentations, maybe four, as part of a meetup on the KCD Discord. And you're starting to move into Twitch, so that your meetups can be recorded and people can watch it later, and more people can participate, those who aren't in the Discord. I'd love to hear a little bit about what motivated you to try the meetups feature and what's driving your desire to share what you know about accessibility?

Sandrina Pereora (03:25):
So, I consider myself a self-taught engineer. And so, I think, with experience, it's like I feel like I need to share back, to give back to the community. So, from the all these years, I was like, "Okay, how can I give back to the community?" I tried tons of things, articles, blogs, speaking, and now, I'm with the meetups and it's going well, and workshops. And I think, what's... My main focus now is accessibility. And why accessibility? When I start learning about front-end, one of my teachers, he taught me about HTML and CSS, and even before JavaScript, he taught me about accessibility. And I was like, "Okay, cool. When I do something, I need to make sure it works for everyone, even people different from me."
But when I start being a front-end engineer in the real world, I started realizing that people were not aware of accessibility. And I was like, okay, this is a gap and this is something that I want to share. So, the lack of awareness from the people around me, I think, it was my main motivation to talk about accessibility. I think that was my main driven. And it has been my main reason for that.

Kent C. Dodds (04:49):
Yeah. Yeah. And I, actually, quick question.

Sandrina Pereora (04:54):
Go for it.

Kent C. Dodds (04:55):
Is?... For accessibility, why do you think that that people are?... Or that web applications struggled to be accessible? Is it because people just aren't aware or is there a actual skill that people need to develop beyond just awareness?

Sandrina Pereora (05:14):
I think the main issue is awareness. I think people don't know. It's not because they don't care about it or there is a lack of interest, I think it's a lack of awareness. If you use a keyboard... If you use a mouse and you type with a keyboard and you can see the website, you just built something in your own image. So, you don't think about people that use something different from you, so that's why people are not aware of accessibility, or aware of other people that use the internet. I think that's only one. And on the same way when you build for Chrome and you just think about Chrome, but then you need to think about all the other browsers, so people are aware of the other browsers, but maybe people are not aware that there are people that only use the keyboard, or people that use screen readers to access the internet. So, I think, that's it, it's the lack of awareness, of people different from you that use internet.

Kent C. Dodds (06:18):
Yeah. I think, in general, that causes a lot of problems beyond accessibility. Like you said, just the lack of experience that other people have. If you just have a bunch of adults who don't have children, building playground equipment or something like that, I don't know, they just... They may not be best equipped to do that. And so, having some more diversity on the team can really improve your products because you have people with different lived experiences and, short of that, you need to have a lot of self-awareness in recognizing that your lived experience is different from others.

Sandrina Pereora (07:05):
Yes. And I think, at the end of the day, is just to trying to put yourself in others people's shoes or even to ask people different from you to try on whatever you are building, and only then, you can truly build something that is accessible and inclusive.

Kent C. Dodds (07:22):
Mm-hmm (affirmative). Yeah. And it can be difficult to find people that are willing or able, or have the time, or that you can pay to try your stuff. And so, the short of that, you can use the tools that they use, and try to limit yourself in the same way that they are limited, and just try to walk in their shoes, so to speak. So... Yeah. What about?... So, there's some of those simple accessibility things like, make sure you have labels on your inputs, and stuff like that, but there are some more complicated user interfaces that people are trying to build that are not built into the web platform. And so, therefore, maybe screen readers don't have built in support for whatever component you're trying to build. For example, a date picker or a tabs UI, or different things like that. Are these the sorts of things that people just need to be aware of, and then they'll build them as accessible components? Or are there specific resources and skills that people need to know about to be able to build accessible user interfaces with those sorts of components?

Sandrina Pereora (08:44):
Yeah. That's the tricky part about the web, for me, web is still a baby, where we have headings, and paragraphs, and inputs. But nowadays, the web is way more than that, it's like [inaudible 00:08:57] models and tubs, and things that hide and show toggles. And when it comes to that, it's awesome if you can do it yourself, but sometimes, it's so tricky to do it properly and to test it, and to make sure that it works as expected. But maybe, my advice is to try to use something that already exists, packages from the community. For example, if you are building a model, think twice, because building an accessible model is harder than it seems, so try to use something from the community, like a package that is agnostic, like JavaScript Vanilla, or if you are with React, there is this Rich UI library that does a lot of built-in components. There is nothing wrong with using packages from the community, because if you use them properly, you already know that the accessibility is covered up on that part.

Kent C. Dodds (09:58):
Yeah, I 100% agree. I would never build my own modal, now that I have Rich UI. And, in particular, there are other component libraries, but I'm a huge fan of Rich UI. They do a phenomenal job of testing. So, let's say that you need to build your own something, some component, there's nothing out there that is going to work for you. What are some of the?... And let's just take a modal as an example, what are some of the resources and tools that you use to make that accessible? How do you know when it's?... For me, if I'm just using it, it's like, "Yeah, I can use this." How do I know that people who are not like me will be able to use this as well? What do I need to be thinking about? What do I check?

Sandrina Pereora (10:47):
So, maybe, to start with, you should be aware of some type of people that use the internet different from you. For example, there are people that only use a keyboard. So, first thing, try to drop your mouse and just try to open, navigate, and close the modal, only with a keyboard. If you do that, that's already a big step. And then if you want to go further regarding a modal for people that use only a screen reader, for example, blind people that can't see the website, they use screen readers, screen readers are this assistive technology that reads the page for you, so try to use a screen reader and see if the modal is announced properly when it's open and when it's closed.
And even when you interact with the modal, try to interact with the modal in a bus. When the bus is shaking and you struggle to close that modal, make sure that the button is big enough to close the modal, for example. It's just trying to think about different use cases from you. It's not a bulletproof solution and it depends from component to component, but yeah, it's all about trying to do it differently from what you are used to do.

Kent C. Dodds (12:15):
I think that's a great principle, in general, that... So, thank you for that. And it makes me think of end-to-end tests, basically. That's what, in a similar way, when we're talking about testing, we want to make our tests resemble the way the software is used, and we automate it so that it can be scalable, right? But for accessibility, it's very difficult to automate accessibility testing, in some ways, it's impossible, at least with our current... By the time that it's possible to automate all accessibility testing, then all of our software will be written by computers anyway, so that's... We don't need to... Don't wait for that. But... Yeah, it just makes me think, "Okay, let's think about how our users are actually using the software, and use it that way, and just see if it's possible.
And I really like your example of using it on a bus. That's not a thing that, that we, typically, would think about, or try to use your software while you're holding a baby, or however people are going to end up using your software, see if you can improve their experience. And I think that's important.

Sandrina Pereora (13:23):
Yeah. And it's such an important part of all the automating test is like, at the moment, only 30, 40%, of accessibility issues can be catched with automative tools. And it's like, you are using a machine to cover a human behavior, so it's tricky. So, you really need to know all to the [inaudible 00:13:46] and how people deal with internet. This is... Accessibility is about people, so you can't put the machine there to say, "Okay, this is 100% accessible."

Kent C. Dodds (13:58):
Yeah, absolutely. And it... As you were saying that, it made me also think about how accessibility is more than just about people who cannot see, or can't use the mouse, or whatever the case may be. It's actually about making your site accessible, with regard to the payload size or the size of your application, if somebody is on a spotty network, how useful or accessible is your application to those people? So, there's a lot to think about when we're thinking about accessibility. Is there any other things that we should be keeping in mind when we're thinking about making sure users have a good experience with our websites?

Sandrina Pereora (14:43):
So, maybe I would like to bring up a myth about accessibility. And I think one of the biggest myths about accessibility, a few years ago, [inaudible 00:14:52] accessibility is only for blind people, but I think the biggest myth at the moment is a disability is a health problem. And a disability is not a health problem. It can be a temporary problem or a ephemeral. There is a spectrum in disability, the type of disabilities that you have. And it's like, it can be a permanent disability like being blind, or it can be a situational disability. For example, you are on the bus, and you are struggling to close that modal. You are having a motor disability at that moment. Or it can be just temporary, like you broke a arm and now you can only use the keyboard.
So, I think that's something that people should be aware is, disability, it can happen to anyone, even you, because you might have some type of disability at some point in your life. So, it's only... Not only about the other people, but it can also be about your future self. So, I think that's something that people should be aware of, that disability affects everyone.

Kent C. Dodds (16:03):
Yeah, absolutely. And I think that's an important point as well. So, we talked a little bit about interaction and how disabilities impact our ability to interact with a web application. What about the visual side of things? So maybe, the people who are using our website can see perfectly fine, their vision is fine, but whether it be... Or sorry, their motor skills are perfectly fine, and they can see the screen, but maybe they... There's a situation that's impacting how well they can see your website or something. What are some of the visual things that we need to take into consideration when we're building web apps?

Sandrina Pereora (16:49):
Okay. So... Maybe the first thing is when you use color in your websites, that you use color in a way that is not the only way to communicate something. For example, imagine that you have a checklist of stuff that is done or undone, don't use only black or gray to differentiate both types, try to use visual elements like icons or text, or explicit text, or... Try to use a secondary element besides color. I think that would be one thing. Actually, that's one of the criterias of WCAG. For those who don't know, WCAG is Web Content Accessibility Guidelines. Is this set of guidelines, and one of the guidelines says that you cannot use color as the only way to express something.
And actually, that's level one of the basic accessibility guidelines to follow. And you cannot automate that, there is no tool to automate, the color was the only way that you used here, that's something that you need to do it manually. Another thing about color is contrast, make sure the contrast respects the ratio. There are a lot of tools out there. And that's one of the things that can be automated, most of the times, to detect color contrast. And regarding color, I'll say, those are the main ones. Use color as a secondary thing, not a primary or only thing. And when you use it, use it with good contrast.

Kent C. Dodds (18:33):
Yeah. And that's one of the things that really is a matter of awareness. There's no real skill involved with displaying more than just a color. And I think most of us have probably experienced the situation where you've got a check box and you're not sure which state the checked state is. It's like, is it checked when it's filled in? Or is it checked when it's empty? I'm not sure which is yes, and which is no in this situation. Yeah.

Sandrina Pereora (19:03):
Oh, I feel that a lot with toggle buttons, like imagine an icon with a speaker and says mute, and I'm like, "Okay, is this muted or not muted? Is it or not?", so you need something else.

Kent C. Dodds (19:17):
Is that button showing me the current state? Or is it showing the state that it will be if I check it?

Sandrina Pereora (19:22):
Yes.

Kent C. Dodds (19:24):
Yeah. And in fact, I'm using Zencastr... Or we're talking through Zencastr and we have this mute, unmute, button. And when I hover over it, it gives me a little title, which is good. Like you should have... When you have icons, if that's all you're going to have, that's okay, so long as, the icon is really descriptive and you get some title thing that pops up and tells you what it means. However, this button only shows a microphone. And I don't know whether that is the current state or the state of what will be, if I click on it. And I have learned, through experience, that it's displaying what the current state is, but... Yeah. There needs to be some indication, especially for new users, or just people, in general, of what the current state is and what this... How the state will change. And that can be, maybe sometimes a difficult thing to do. I'm not sure how I would change this Zencastr, mute, unmute, button to make that better, but... Yeah. [crosstalk 00:20:20].

Sandrina Pereora (20:20):
Yeah. And that's not an accessibility issue, that's a usability issue. It might be accessible if it has all the content to not only visually, but program... Not programmatic, but semantically speaking, that it say that whatever the action of this button is through visually, even a [inaudible 00:20:44], or a class, or [inaudible 00:20:46] label or something like that. But besides that, you need to make sure that it makes sense for all, for everyone who is using it, so it's an usability issue.

Kent C. Dodds (20:57):
Yeah. That's true. It's the... This button could perhaps be just as accessible to everybody because of the technologies that they use. But now, we have a secondary issue that's impacting everybody else and that's usability.

Sandrina Pereora (21:12):
Yeah.

Kent C. Dodds (21:13):
So, when developers get accessibility bugs... Or maybe they're not labeled as bugs, but when people get accessibility issues that come onto their plate, how should they be thinking about those?

Sandrina Pereora (21:26):
Accessibility issue. So, if you find something... Something that has some accessibility issue and you create a task for it, I think my tip would be to not label that task as an enhancement or an improvement. Accessibility is not an enhancement, accessibility is a requirement. So, mark that task as a bug. If it's not working for someone, it's a bug. So, try to look at your backlog or your current tasks, and change the category fields, and mark that as a bug. So, you need to prioritize that, because if you fix it, you are making someone's life much better out there.

Kent C. Dodds (22:09):
Yeah. And what's interesting too is, for some people, this might... This particular bug might end up costing the company a lot of money in lawsuit fees if it's not fixed. I'm... I think about a Domino's, maybe a year or two ago, had a big kerfuffle around accessibility of their website. And they... I think they decided to do something stupid and settle for $3 million or something, rather than fix their website, which is like... I mean, I'll fix your website for 250,000.

Sandrina Pereora (22:44):
Exactly.

Kent C. Dodds (22:49):
Yeah. It's just outrageous, but you can get nailed by... For not making your website accessible. So, I would say it's a bug and it's probably high priority to be fixed bug, when you [crosstalk 00:23:03].

Sandrina Pereora (23:03):
And probably an easy bug to fix, most of the bugs are easy, most of it. If it's not that easy, try to look for the community solutions and reuse something that already exists. If it's hard to make an accessible modal, just go and reach some library out there.

Kent C. Dodds (23:21):
Yeah. Absolutely. For me, I think most web apps are relative... I mean, I'm not going to say they're trivial because there are components that are difficult to make accessible. Absolutely. It takes a special skillset and you got to learn that, but for most problems that most application face, that's pretty simple. And like you said earlier, it takes awareness, sometimes though, there are differences in the technologies that people are using that needs to be taken into account. I think about, a few years ago, we had all the browser wars and it was just really difficult to support all the browsers, now, that has settled down quite a bit, and it's pretty easy, most of the time, to support all the browsers. But I have experienced different screen readers and assistive technologies, and they behave pretty differently. Have you had some trouble with that and how do you address the cross compatibility issues with the different assistive technologies?

Sandrina Pereora (24:19):
Yeah, that's a tricky part. So, voiceover, it's like the screen reader for Mac, so I have a Mac, so I only use voiceover, I can... I don't have the ability to use another type of screen readers. But one thing that I really like is maybe people that are listening or reading this might be aware of, Can I Use, for CSS features. There is this website called A11y Support. So, A, 11, Y, support dot com. I think it's dot com. Dot IO, sorry. Dot IO. So, there is this website called A11y support dot IO, works like Can I Use, but for screen reader supports, and basically, it's a huge list of all the [inaudible 00:25:05] attributes and all they work with in different screen readers. So, when I'm in doubt with something, I go for this and I take this as my source of true, might be not 100% decorated, but it helps me a lot with it.

Kent C. Dodds (25:21):
Yeah. That's actually really helpful. Thank you for sharing that. Because I recently was working on a forum, and in preparing an updated version of Epic React, I'm going to include a special section on accessibility. I eventually plan on making an entire workshop on accessibility, but I wanted to, at least, teach a single lesson on accessibility, just to give a quick intro before... So that, people have that until I make a full workshop. And I was really struggling because one thing that I've noticed is that screen readers seem to... They follow the RESPEC, but then they also try to compensate for a developer's lack of following the RESPEC.
So, they try to do a little bit of extra work, which counteracts what we're trying to do when we follow the RESPEC. And so, I noticed when I was typing in this input, I would have an ARIA live or a region over here, and it would tell the user that the form is invalid now, or whatever. And it would start reading that, and then it would stop reading that, and read what the user just typed. I'm like, "I can't get it to read what I want it to read." Do you run into problems like that? And how do you deal with those sorts of issues?

Sandrina Pereora (26:38):
Yes. So, I can speak as a true screen reader user because I don't use screen reader on the daily basis. So, I don't know as much, I know like 5%, compared to a real screen reader person. Screen... I know like 5% of what the person that uses a screen reader on daily life, they know. So, for me, it's like, when I face one of those issues where the screen reader is announcing something, and then it jumps to another thing, and maybe I'm messed up with some shortcut is like, I keep in mind that most of the people who use screen readers, they listen, the screen reader like, four, five times the speed of what I and you listen to a screen reader. So, it's like, they will navigate the webpage way faster than with the... When we are moving around.
So, it's like, maybe they will be okay, but when I'm in doubt, I always ask the community like Twitter, I tweet, "People, I have a question here", just send it to it, asking for feedback. Once again, I try to put not... I not only put myself on other's people's shoes, but I also ask the real user's here, "Look, how do you deal with this? What are you expecting?" Because I don't know the answers for that. And that's one of the beauties about accessibility is you need to look for the solutions, and to be mindful about the current solutions, and the choice that you make, and that there are trade offs. And maybe there isn't a perfect solution, but if you are aware of the trade-offs and the current solutions, you'll get the best solution that is out there, currently, I think. Basically, it's all about finding a balance and look for what the community wants or needs the most.

Kent C. Dodds (28:51):
Yeah, I like that a lot. And if it's for a work project, maybe you can convince your manager to hire somebody, or at least a contract with somebody who has that lived experience of using these technologies, because it is... Yeah, it's tricky. My approach has been similar where I reach out to the community, maybe find somebody who can I can contract with, but in general, it's just try to follow the RESPEC as best you can, and hope that the screen readers deal with that well. So, Sandrina, this has just been a pleasure to chat with you. I'd love to chat more, but we're down to the end of our time. And we do have some homework for folks. So, this one actually is fun. You get to choose. But you have to do, at least one, you can do all of them if you like, but here are the things that you need to choose between.
So... And all of these app... Or all of these, it's when you're using the app that you're working on for work or whatever, whatever app you want to improve the accessibility on. So, first, try to disable all the CSS. And we didn't talk about this too much, but why would it be useful for people to disable CSS on their website?

Sandrina Pereora (30:09):
So, this is like a workaround if you are scared of using the screen reader, as a first try. So, the screen reader, the way a screen reader announces the content is about writing, interpreting the HTML, right? So, if your write semantic HTML, the screen reader will announce it properly. So, if you disable the CSS and if the page still makes sense, visually, so probably, you are on a right path to create an accessible website. So, that's a easy way to double check if your website makes sense, if those headings are there, if the buttons are real buttons and not spans, if the list is really a list, not a bunch of spans again, and [inaudible 00:30:54]. So, disabling the CSS unmasks the beauty of your website and puts the semantics on test.

Kent C. Dodds (31:05):
Yeah, that's great. Good. So, that's your first option, disable the CSS. The next is, use your app in the sunlight, that can help you with the contrast issues we talked about earlier. The third option is use your app with a keyboard only. So, put the mouse in the drawer or whatever, try to use your app with only the keyboard, that will reveal a lot about... And try to open your modals and close your models, all of that. And then the last one, this is for the masters of you out there, or the more brave, which is all of you, of course, use your app blindfolded with a screen reader. So, that will probably require that you use it only with the keyboard as well. But... Yeah. Those are your four options. Definitely, give at least one of those a try and maybe all four of them. Do you have anything to add, Sandrina?

Sandrina Pereora (31:55):
Not at the moment, maybe one last tip is to remember to put yourself on others people shoes. Be open to listen to other people, to try different things, and don't be scared with accessibility. With enough practice, you'll get there. And if you are already aware of it, it's already a good start. Yeah.

Kent C. Dodds (32:23):
That's great. Thank you so much. It's been a pleasure to have you. What's the best place for people to keep up with what you're doing?

Sandrina Pereora (32:30):
At the moment. I'm very, very present at Twitter, so you can just follow me there. A, underscore Sandrina, underscore P, I'll be there. Yeah.

Kent C. Dodds (32:40):
Awesome. Very good. Hey, thanks so much. And we'll see you all in the future. Goodbye.

Sandrina Pereora (32:45):
Bye-bye.