00:00:00 Kent: Hello everybody, I'm super excited to be joined today by my friend Sandrina. I'm going to try your last name and you can correct me. It's Pereira?

00:00:11 Sandrian: Pereira.

00:00:12 Kent: Pereira. Well, thank you. That's not the first time that I've tried to pronounce your name on a podcast before so yeah, I don't really

00:00:24 Sandrian: have a good 1. It's okay.

00:00:27 Kent: No, it's not though like for your People who grew up in that you're from Portugal. Is that right?

00:00:33 Sandrian: Yeah. Yeah.

00:00:34 Kent: Yeah, so people in Portugal It's like a normal last name. So it's just me. I I'm the 1 at fault here But yes, thank you so much for joining me and as Sandrine and I go back I always like to talk about how we met. And I think, I don't know if I knew you before

00:00:54 Discord. I think that's where I met you was in my Discord.

00:00:59 Sandrian: Officially, yeah.

00:01:00 Kent: Yeah, yeah. And we did some meetups, some KCD meetups where you share your screen or answer questions, do like a little, kind of like a talk sort of thing virtually. And You did a couple of those about accessibility. A bunch of people joined, it was pretty cool. And we don't really,

00:01:21 I don't do, I have the meetups stuff anymore. The bot doesn't really facilitate those on the Discord anymore. But you, I don't know whether you've been doing this before, but after that, you ran a bunch of workshops on accessibility and stuff too, and just been doing a lot of cool stuff with accessibility in the past. So

00:01:41 that is how we got to know each other. I'd love for you to give your own introduction though. So can you tell our audience a little bit about who you are and what you stand for and all that?

00:01:53 Sandrian: Yeah, so, hey there, I'm Sandrina. I'm from Portugal, but currently I'm based in Copenhagen for a short period of time. That's why I apologize for any troubles with my mic. But yeah, who I am. Currently, I'm a staff front-end engineer at remote.com. So it's like a remote company that literally

00:02:13 the name is remote. And there I'm all over, you know, React ecosystem, headless systems, currently very focused on how to create and manage forms at large scale. So it's pretty intense. And you know, the downside of that is that I don't touch

00:02:34 Accessibility on my daily basis as much as I used to do like 1 year ago But it's still something that I'm really when I see something wrong. I always you know call out for it. So even if I don't do accessibility on my day to day, it's something I care about.

00:02:52 Kent: Well, yeah, that's definitely something I wanna talk about today. Also wanna get into some of the design system stuff and the forms at scale. I think that'd be really interesting. And so in the workshops, where we get into accessibility is actually with forms. We talked about focus management and proper labeling

00:03:13 of fields and that sort of thing. And so, yeah, I'd like if you could just give us a like a quick idea of why accessibility is important. Just pretty quick, like people should know that it's important, but why is it important to you?

00:03:33 Sandrian: Why is it important for me? I don't have a fancy background story like, oh, how did I start in accessibility? But for me it's important because, you know, most people when they started to code, it was for fun, you know, I build websites for fun. But the thing is, when you are a professional software engineer, it's not just for fun. It's

00:03:53 for other real people. And it's kind of, you are the architecture, the architect of the digital world, you know? So the same way we have architects with laws about how to build an accessible building, you know, we should do the same in the internet. So if you build something, it's not just for you to use it, it's for other people

00:04:14 that are different from you. So it's kind of your duty as an engineer to make sure that it's successful for everyone. As simple as that. It's like almost a human right, but yeah.

00:04:27 Kent: Yeah, I think that it really comes down to caring about other people, right? And their experience. And what I find is that the more accessible I make my application to blind people, or to people who can only use a keyboard

00:04:48 and those individuals, the better the experience is for everybody as well. Anyway, like before we were using the physical building metaphor, having a ramp that leads to your front door. Like maybe you've got steps because your front door is up there a ways or whatever, but having a ramp

00:05:08 is useful for wheelchair users, but it's also useful for anybody who has a dolly that they're pulling a big box or even those kind of temporary disabilities that we talked about, or maybe you're coming back to the web, maybe you're holding a baby

00:05:28 and so you can only use 1 hand and so being able to navigate around with 1 hand is very useful, or maybe you broke your arm or whatever. So everybody, the thing is, it's not, accessibility is not necessarily about 10 or 20% of users. It's about 100% of the

00:05:49 users 10 or 20% of the time. And so like your efforts in accessibility will affect a lot more or everybody in a really positive way.

00:06:02 Sandrian: Yeah. I must say though that even though we try to sell accessibility as like something that affects everyone or that benefits everyone, if you think about the dark theme and the light theme, which is like a trend nowadays, that's like a perk. It's like a little bonus. Oh, now I have the dark theme. So cool.

00:06:23 But for those 10 or 20% of people, the minority, they are really the ones that really, really appreciate it because for them it's not a perk. For them it's what really makes a difference, to enjoy the web, to read the newspaper because they do it digitally more easily than in a real paper.

00:06:43 Stuff like that that we take for granted and for them is like the difference between having a good day or just you know a bad day.

00:06:52 Kent: Yeah, yeah for sure that like I so I said it affects 100% of the users 20 to 30% of the time but for users who use screen readers and can only use a keyboard and stuff, that affects them 100% of the time. And like, can you imagine living that kind of a life where you're just

00:07:12 constantly facing these different websites or real world experiences where nobody thought about you. That just, that would stink. I would hate that.

00:07:25 Sandrian: That's why the secret is to really care, you know, really care about people. You'll make the difference. And it's not that hard most of the times. Sometimes it is, but most of the times it's not.

00:07:35 Kent: Yes, yeah. It can get pretty complicated with components that are not native to the web, like a combo box or modals and stuff like that. But that's why we have libraries from people who put those things together so we can use those. So that is cool. So, so far we've talked a little

00:07:55 bit about screen readers and like keyboard users, but there's like lots of different categories of accessibility that you need to consider on the web like Color and text and stuff like that. Do you want to talk about those 2?

00:08:10 Sandrian: Maybe I could start with the you know, the The I'm forgetting here the name but it's like in accessibility you have this concept, which is POUR, I'm forgetting the name here, it's like the pilars of accessibility. So perceivable, operable, Understandable

00:08:30 and robust. So perceivable is basically everything around visually, you know, whatever that you are doing visually, make sure that people cannot see, also can perceive whatever you are building. You know, operable is basically everything that you interact, that you build, that is interaction like clicking buttons, check

00:08:50 boxes, you know, whatever, make sure that those are also interacted, not only with the mouse, but maybe also with the keyboard. Understandable is more about the text, you know, like whatever you put on your page, make sure that your users actually understand, you know, that they understand the flow, where to click, you know, that's not only about accessibility,

00:09:10 but also about usability. So it's kind of 2 fields that merge together. And lately, you know, yeah.

00:09:17 Kent: Oh, sorry. Would that also be like, even the way that things are worded like the words that you use and Have like the content I think

00:09:31 Sandrian: You know It really depends on the audience of your website and what you are trying to aim for the compliance, if it's just 1A, AA, AAA. But for example, if you want to use acronyms, AAA say that you should avoid acronyms at all costs. And if you use them, it really must include the full the meaning of an

00:09:51 acronym, you know. For example, or even, you know, whatever the content that you are trying to put on a page, make sure that it's not, you know, jargon for the main audience, if that makes sense. It really depends. And this is something that goes away from your job as an engineer. It's more like a job for the designer

00:10:11 or the product manager or the copywriter, you know. So it's like accessibility is not only for engineers. It's for, you know, a set of people, like for your entire team.

00:10:20 Kent: Yeah, absolutely. And then the last 1 is robust.

00:10:23 Sandrian: Yeah, robust. So basically it's like, please don't use divs and spans everywhere. It's basically that, it's like use HTML properly, use buttons and the proper attributes, like for forms, as you mentioned, please use a proper input instead of another span with fancy JavaScript.

00:10:43 Kent: Yeah, that actually, that makes me think of progressive enhancement and like making it so that your application is robust enough to be able to function without any client-side JavaScript as well, where you're using like actual form submissions And if you don't have JavaScript in the client, then

00:11:03 let's do a full page refresh. That's fine. But like use the platform.

00:11:09 Sandrian: So, cool. So- I've already bring so much.

00:11:13 Kent: Yeah, yeah, totally. So P-O-U-R. That is good. I'd never heard of that before. So that really helps contextualize.

00:11:20 Sandrian: I'm having a blank year. It's the principles, that's it. 4 principles of accessibility. Ah, then, you know.

00:11:32 Kent: That's good, that's good. Awesome, yeah, so that's really helpful. Now, you have been working on, or like, you've been working with accessibility for a long time and then you, now, I don't know if this was a new job or you got a promotion, but now you're a staff engineer Promotion

00:11:52 awesome. Well, congratulations so in the How has that been being a staff engineer? And what does that really even mean for the company you're at?

00:12:05 Sandrian: Okay, that's a brilliant question because what it means to be a staff engineer really depends from company to company. You know, the expectations in 1 company might be super different from another company. So whatever I'm about to say might not apply in other companies. But here at particular year at remote, the staff engineer

00:12:25 basically is an engineer that impacts multiple teams and it has a strong influence, not only technically, but on the product side as well. So to kind of be the gap, not the gap, sorry, the bridge and to fill the gap between product and engineering across multiple teams. Remote

00:12:45 For those who don't know, Remote is basically a HR platform where it handles all the paperwork to hire someone globally. So we deal a lot with, I have this internal joke, which is like Remote is 50% of forms and the other 50% is tables. So it's like all about gathering information about the employees, like salary, time-offs,

00:13:06 expenses, benefits, anything that comes to your mind, and managing all that data in the platform. So it demands a lot of business and product knowledge. So a staff engineer also needs to have very solid knowledge about what the product is about.

00:13:27 And also feel the gap here from a technical perspective on how to solve those problems that the business is trying to solve. You know,

00:13:35 Kent: that makes a lot of sense.

00:13:36 Sandrian: No, it was super abstract again. It's really, no, no,

00:13:40 Kent: it's actually, that, that does make a lot of sense. I like in, lots of jobs or, or my early jobs. I remember, like I worked at a business intelligence company, and then I worked at a voiceover IP company, and then I worked at a task manager, like not really a JIRA, but like sort of that

00:14:00 type of a thing. And each 1 of those early jobs, like the business itself was like, yeah, that's kind of interesting, but I'm more interested in the code. And I wanted to be like, just really deep into the code. But The longer that I've been an engineer, the more I have realized that the ones who

00:14:20 make the biggest impact are the ones who really understand the needs of the business and what your code is actually being deployed to actually accomplish. And so that makes sense that as you get higher in the ranks, you're expected to make a bigger impact. And so you're also expected to understand the business at a much

00:14:40 deeper level.

00:14:41 Sandrian: Yeah. Yeah, 1 thing that I've learned, so before I was a staff engineer, I was a manager of a team and there was a lot of things that I've learned there as a manager. And 1 of the things was like, well, maybe the code is not the most important thing at the end of the day, you know, because if your business, I don't know,

00:15:02 If this particular business problem is not solved on time, maybe your perfect code will never go live, you know? It's a balance, you know? Like that's a hard lesson that you learn when you are a manager. And even as a staff is like, it's a trade off, you know, it's a constant trade off here.

00:15:23 Kent: But you don't find yourself as you go like higher in the ranks, you don't really find yourself working in the code as much. Has that been your experience?

00:15:36 Sandrian: Currently, I'm still working a lot closely to the code. I might not be the 1 coding directly, but I'm definitely involved in the decision, in the code reviews, in prototypes, in special documentation. I'm part of a team that is kind of creating a new internal

00:15:56 technology, and I'm helping other engineers to learn this technology, to adopt the technology in their own projects. So I'm kind of an advocate internally. But no, I don't code as much as I did before. But the thing is, as a staff, you are not expected to code as much as before.

00:16:17 Otherwise, you are not a staff, you are just a senior plus, you know.

00:16:23 Kent: Yeah, that does make sense. And so you, I'm guessing that the teams that you're kind of responsible for bridging that gap. They're all like related teams and you just have to like, do you end up being kind of like a team lead

00:16:43 role or do those teams have their own team leads.

00:16:47 Sandrian: They have, they have their own managers here. If you, by team lead, you mean tech lead? Yeah, yeah, tech lead. Usually I'm not, if I'm a, when I'm a tech lead, it's not tech lead of people, it's a tech lead of projects. So I have a couple of projects and I'm leading that project and then whoever is in the project with me if that

00:17:07 makes sense Yeah, so managers are responsible for people and staffs are responsible of projects

00:17:15 Kent: Yeah, cool. That makes sense. And 1 of the projects that you're working on right now is a design system. Is that right? You want to tell us a little bit

00:17:23 Sandrian: about that? Not exactly the design system. It's a system, but not part of the design system.

00:17:30 Kent: Okay, Okay. Let's hear about that.

00:17:32 Sandrian: Oh, okay. How can I try to explain this? It's like, as I said before, off of remote is forms. And when I say half is like, imagine that when you are on board, someone from United States, like when you need a new employee, like you have a company and you want to hire someone in the United States, the employee

00:17:53 needs to fill a bunch of forms, like your personal details, your bank details, address details. And then you need to fill the salary, the time off, all the benefits. You can imagine the number of forms. And I'll multiply that by 100 countries, which is more or less. So we are talking about

00:18:13 thousands of forms. How do you imagine these forms are? They cannot be hardcoded in the code ways.

00:18:18 Kent: No, no, you got to have a CMS for that.

00:18:21 Sandrian: You're going to need a headless system to handle all these forms. And then imagine, OK, you have this picture, right? Now let's go back to the very simple form. For example, a form that asks for the time off. And it says, oh, the time off in United States needs to be at least 10 days, right?

00:18:41 I think it's

00:18:41 Kent: 10 days. I have no idea.

00:18:43 Sandrian: No, 10 days, which is another topic, but okay, it's 10 days minimum. And you do that validation on the front end, you have your front end, minimum 10, then it goes to the API and the API also needs a validation, minimum 10. And now you have duplicated validation. So you don't

00:19:03 only need to build a form on the front end, you also do it on the back end. So you twice the work. So we need a system that works on both front end and back end where you can share the logic, the validations, you know, conditional fields, the label descriptions, all of that. How can you do it? So that headless system is what I'm working on.

00:19:24 Kent: Okay, okay. Yeah, we actually, so that aligns really nicely with the workshop because there's an exercise in the workshop where I show schema validation and we use Zod Schema to do that. And then a library called Conform will convert that Zod Schema

00:19:44 into HTML attributes that you can apply. And it also runs the Zod parsing on the client as well as on the server to share that. So yeah, that actually aligns really well. So, so far, how do you accomplish that? Or I guess you're still working on it.

00:20:01 Sandrian: Yeah, so we are not using Zod. It was 1 of the things that we looked into it, but we are using this tool, not tool, a specification called JSON Schemas.

00:20:12 Kent: Oh yeah, yeah, sure.

00:20:13 Sandrian: Yeah, so basically we are using JSON Schemas to describe these, first these rules, like what we call country rules, for example, the time off for United States is at least 10 days. And then we also use those same JSON schemas to describe the forms. So field 1, field 2, field 3,

00:20:34 with all the labels, description, validations, conditionals. And it can be super powerful. And the thing is, it's JSON, so JSON, the advantage of it is that it works with any language. You can put it on the back end with any language, you can put it on the front end with any language. You just need to build kind of the validators or the parsers

00:20:55 to understand and compile that JSON in actual, you know, code. For example, on our side, the back end is Elixir, on the front end is React. So we kind of have a parser that transforms that to JavaScript and to React. And then eventually you have an actual form, with all the validations and accessibility in mind. But the thing is,

00:21:15 the actual form is already that, yeah, that's the design system, the visual thing, I'm a little bit behind that. I'm just on the headless part with the JSON schemas.

00:21:26 Kent: Yeah, yeah, that makes a lot of sense. And actually, if I can validate your decision for what it's worth. Years ago, I worked on a form library for Angular called Angular Formly. And 1 of the really awesome things that a contributor did was put together

00:21:47 a JSON schema converter. So it would convert it from JSON schema into our API. And they had like thousands of forms. And the real, really nice benefit of JSON Schema is that it's serializable, so you can save it in a database. And I'm guessing that's probably

00:22:05 Sandrian: what you're doing. Yeah. Exactly. So that's also our solution to not have the forms are coded in your code base. So each time, for example, you need to imagine that the law changes tomorrow, and now it will be 20 days in the United States. We don't need engineers to change it. Then the thing is we have

00:22:26 UIs, like tools in our back office for our internal operations to go there and change directly. And that will change the JSON schema that is stored on the database. So we kind of also have this meta level where you have JSON schemas to generate JSON schemas.

00:22:43 Kent: Oh yeah, sure.

00:22:44 Sandrian: You know?

00:22:46 Kent: Yeah, yeah.

00:22:46 Sandrian: And then you have the form builder where the operations can, you know, literally create, oh, I have this field and now I ask this and this and that and that. And then you need the JSON schema for each type of field that you allow the operations to create, like a JSON scheme for a number and JSON scheme for a select field. So it can be very, you know,

00:23:06 meta JSON scheme averse.

00:23:09 Kent: Yeah, yeah, totally. So you have like a special app that's, you're kind of building a CMS for managing forms.

00:23:20 Sandrian: Yeah, CMS, CMS sounds boring, but yeah.

00:23:23 Kent: Yeah. Yeah, cool. So 1 challenge that I, that just occurred to me is, What do you do about when the law changes and now there's a new field that's required? And so you've got all this data in your database that previous employees had already filled out and saved,

00:23:44 but now we've got this new required field. Do you have to do some sort of migration? You set a default value for that field for them? Or do you have to email them all and say, you've got to fill this out?

00:23:55 Sandrian: Yeah, that's the thing. The thing about this is that all this data is attached to a contract. Your contract says that you have 10 days off. If the law changes tomorrow, basically we need to do a new contract. So we cannot do a migration like that, you know, and change everyone in 1 sec.

00:24:16 I wish we could because it would simplify everyone's life, but as you can imagine, to be compliant, we cannot do that. So basically what we have in mind here is like we have a kind of automated system that you know, search through every employment, check the ones that are not compliant anymore, and then

00:24:36 triggers a notification for their employers. So, you know, the boss of each employee and, you know, it creates a new, what we call a new contract amendment or, you know, so basically a new version of the contract where both parties need to assign and okay, now you are compliant again with the law.

00:24:54 Kent: Interesting. So

00:24:56 Sandrian: some of them are super easy. Some of them, it, it cannot be automated. You know, it really is to be case by case, depending on the country and depending on the law and depending on the effective date that the law changes. For example, oh, you know, the new salary will be, I don't know, 3000, but only applied next month.

00:25:16 So we also need a system to deal with that.

00:25:21 Kent: Yeah. Wow. Sounds complicated. I guess that's why it can be a company.

00:25:26 Sandrian: Exactly. This is a real problem. When you try to build a remote global team and you need to handle all these law little things across all the countries. Yeah, obviously remote as here a solid business case to solve.

00:25:44 Kent: Yeah, absolutely. Well, very cool. So, yeah, I, I think that I've kind of asked all the things that I had on my mind. Is there anything else that you think it would be really useful to chat about before we wrap up?

00:26:00 Sandrian: About accessibility or being a staff or anything else?

00:26:03 Kent: Yeah, any of those things. I think like, so we covered several topics on accessibility and being a staff engineer. I guess 1 question I have about the staff engineer is Do you miss coding as much as you were before? Like working on the actual product rather than just doing reviews

00:26:23 and prototypes and stuff like that?

00:26:26 Sandrian: I still work on the code. So I don't miss it. When I was a manager, yes, I miss it because I didn't code as much. But now as a staff, I still code, you know, I'm still close to the code. At least I'm close to the code. I'm close to understanding the technical

00:26:46 details about something. So I don't miss it. And I quite enjoy being a little, you know, giving room for others to also grow. There is this book that I really, really love is the Stuff Engineer Path by Tanya Rayleigh. And 1 of the things that she said on the book is

00:27:07 if you have like if you have time to do everything then you don't allow others to grow And that's the thing that kind of clicked for me as a staff, is like, okay, let me do something else and the others, or let me help others to do it so that I don't need to take the lead all the time. And that's

00:27:27 quite beautiful because then you can learn so many other things about, you know, an engineer. It's code is not the only thing that matters on your day to day.

00:27:38 Kent: Oh, I think that's fantastic. And I'm glad to hear that you do have plenty of opportunity to code. I know a lot of people kind of as you go higher in the ranks of in the company, you often people complain that they don't get to code as much. But I guess you were able to take a track

00:27:58 that allows you to keep doing what you enjoy.

00:28:00 Sandrian: You know, the IC track you are allowed to, if it was a management track, then yeah, it's not expected for you to code. So it's kind of this balance. And again, it really depends from company to company, even at remote, like we have staff that code every day And they are just a different archetype of stuff compared

00:28:21 to me. So it's not just 1 is better than the other. It's just different personas of stuff. Yeah. But yeah, to answer your question, I don't know what else I have to say here. With accessibility, you don't need to solve it all alone. I think that's my tip for the developers. You

00:28:41 need to find an ally here to help you solve the problems. That would be a tip here. And for people who are looking to become a staff, try to improve your communication skills with people who are not engineers. I think that would be

00:29:01 a way to improve your skills as an engineer.

00:29:05 Kent: I think those are great tips. Thank you for bringing those up. Now, if anybody has a desire to reach out to you or follow what you're doing and stuff like that. What is the best way for them to do that?

00:29:21 Sandrian: Well, you have not Twitter anymore, but the X platform. So I'm there, you know, at a underscore Sundrina underscore P and There you'll find everything else about me, you know the website contact Blah-blah-blah, you know traditional LinkedIn if you want to so I'm pretty easily reachable

00:29:41 online

00:29:43 Kent: Super. All right, Sandrina. Thank you so much. This has been just a pleasure to visit with you. Always enjoy our chats. And yeah, we'll keep up with you as you continue on your journey. So thank you so much.

00:29:58 Sandrian: Thank you so much, Kent, and good luck with everything with Epic Dev and, you know, epic success with you

00:30:06 Kent: Thank you very much. Bye everybody

00:30:09 Sandrian: Bye