Accessibility and Developer Experience - Kitty Giraudel (Gorillas)

On this episode, our hosts Sarah and Bryan are chatting about accessibility with Kitty Giraudel. Kitty is a front-end developer and accessibility specialist who is currently leading the front-end team at Gorillas. Before this, they have led the front-end team to rebuild the web platform at N26, with a strong focus on accessibility.

We are going to talk about accessibility and its implications when it comes to Developer Experience.

- Can Developer Experience and User Experience cohabitate without hurting each other? Can they help each other out?
- What are the things you want to watch out for in accessibility?
- Are we giving as much attention to accessibility as we are to developer experience?

• Kitty Giraudel: @kittygiraudel
• Sarah Dayan: @frontstuff_io / sarahdayan.dev
• Bryan Robinson: @brob
• Gorillas: @gorillasapp / gorillas.io
• Algolia: @algolia / algolia.com

Transcript

Kitty Giraudel: 0:00

It's like, it's never done. Like it's not on/off switch, right. You're not accessible or not accessible. Having also at a company level, at an executive level and authority level in, in organization telling we need to reach compliance because, well, you need to reach compliance as a company, right. Essentially, but then we need to do more in terms of inclusivity and accessibility and caring for more users or caring for the same users, but better. Right.

Sarah Dayan: 0:32

Hi everyone. And welcome to developer experience a podcast by Algolia. We chat with guests who build products or developers about their developer experience strategy, what it means for them, why it's important and so on. I'm Sarah Dayan, and I am joined by my co-host, Bryan Robinson, how is it going Bryan?

Bryan Robinson: 0:54

Going well, Sarah, thanks for having me as a co-host as always.

Sarah Dayan: 0:57

So on today's episode, we are going to talk about accessibility and its implications. When it comes to developer experience, can developer experience and user experience cohabitate without hurting each other, can they help each other out? What are the things that you want to watch out for? And are we giving as much attention to accessibility as we are to developer experience? So to discuss this important topic, we are floor to have Kitty Giraudel with us today. Kitty is a frontend developer and accessibility specialist who is currently leading the frontend team at gorillas. Before this, they have led the frontend team to rebuild the platform at N 26 with a strong focus on accessibility. But aside from this, you might already know Kitty for the massive contribution to the SAS. And I'm talking about a CSS pre-com compiler, not software as a service. So SAS ecosystem, there are accessibility focused project, such as the dialogue up in source library, their alley advanced calendar, and the many high quality block posts about accessibility, inclusion and workplace safety on their blog. Hey Kitty y. Hello.

Kitty Giraudel: 2:17

Hey, nice. Thank you for having me very nice to be with you today.

Sarah Dayan: 2:20

Yeah, we're really happy to have you on, uh, uh, this is a really interesting topic, a really deep topic I'm really excited to get started. So when we talk about accessibility, let's get right to the chase. There's still a bias. Every time you see a conversation online, or you talk about it with people, even experience people, there's still a bias that this is about catering to user with specific disabilities, like physical cognitive impairments. And while it does cover those accessibility, as I understand it is mostly about inclusion and catering to as many people and situations as possible. So I'd love to know, can you tell us more on what accessibility is about and why it matters?

Kitty Giraudel: 3:07

That is an interesting and surprisingly difficult first question, actually, I think there's essentially two sort of parts to this answer at a core accessibility is a discipline. If you will, to ensure that everyone can use a service, a product, you name it, regardless of whether they have any sort of disability, as you mentioned, whether it's cognitive auditor visual and so on. And over the years, we had a lot of the discourse around accessibility shifting towards accessibility benefits, everyone. And it has been somewhat necessary because activity has a tendency to be under prioritized in companies. So essentially to push it and have a buy-in, we tend to say, you know, it benefits everyone. So it, it is not about a minority of users. Everyone gets to benefit from it. Right? And that is true to, to certain extent, as in, I mean, better software, quality benefits, everyone. This is, you know, because we were saying, I think there is a bit of a complexity in, in that discourse though, which is that it tends to decenter disabled people from flexibility topic, which is a problem. The more we exclusively push that activities for everyone, um, argument or line, if you will, the less, we sort of focus our effort around the people who need to benefit from the discipline, right? So disabled people. So, uh, that's already an interesting sort of interesting topic to have because focusing extra and disabled people, unfortunately doesn't get the buying it needs. And it deserves, most companies is a little forgotten or completely forgotten in unfortunately too many, too many companies. And yeah. And so the way to push it is essentially like, Hey, this is better. Um, this is more inclusive. This is, uh, better for our audience. This will make sure we have more customers, a more prospect, right. We need to remember for who would do that and to call it right.

Bryan Robinson: 5:06

I think that centering argument is so important and it's such an interesting thing to think about because we love buzzwords. And so like accessibility was a buzzword for a little bit, but I think that we, we centered around things that were like very technical, like, oh, we need to make sure it's good for screen readers. It's less about making sure everyone has access to it. I wonder if there's something to be said about using, it's terrible to say, like the, the buzz wordiness of inclusion right now. Like that's a thing that, that a lot of companies are paying a lot of service to maybe just in text and then what they say. But I wonder if, if there's a, a way to utilize that and bring that into the conversation in a broader scope to make these other things happen as well.

Kitty Giraudel: 5:47

Yeah, for sure. I mean, intimately it's accessibility and, and diversity and inclusion, they are related topics, right? Diversity and inclusion is not about bringing more women into the workplace, you know, especially more white women, which is usually how it's being considered by, um, executive suites. So hiring disabled people, hiring people of color, hiring trans people and so on and so forth. Visc all comes into, into diversity inclusion and having structures to retain them, not just hiring, but making sure they can stay and thrive. Right. And often more often than not, unfortunately disabled people are kind of forgotten from diversity and inclusion topics. We need both. We need both, we need the conversation to be, uh, to be sort of encompassing of both topics, right? We can't just talk about accessibility without bringing the fact that it is a, we build more inclusive services and product and therefore we'll improve the bottom line. Right. And we also shouldn't talk about diversity inclusion without considering the accessibility aspect of it and, you know, hiring and, and retaining and caring for, uh, disabled, disabled users, disabled employees, and so on. Right? So those topics needs to be way Morelock than they are currently. I think we see progress in that aspect though. I think in the tech industry, you see more, you see more electricity advocate that are also very much invested in, uh, workplace diversity, um, workplace safety and the right. You also see a lot of initiatives that started as very much, we are very white male centric company and we need to diversify because that press or whatever. Right. And then you see initial sort of like transforming into making also more accessible product, more accessible service in the long run. So yeah, it's interesting to, to see the, sort of the connection between the two, the two topics.

Sarah Dayan: 7:31

Yeah. I think this is so important that you mentioned that this argument of yeah. Accessibility is for everyone while it's true. It kind of moves the conversation to, Hey, we love everybody. And, uh, like the, the experience of everybody is important, but at the center of like the people suffering right now for, from the web not being accessible first or for and foremost, it's not everybody. So yes, ultimately yeah, the, the line gets better and everybody feels better and everybody has a better experience out of accessibility efforts. But we need to really remember that when we say that we kind of erase the, like the experience of really specific people, that for a long time have been totally for, or gotten totally outside of the conversation because we could not care less. And personally, the way I see accessibility is also like taking a step back and realizing that every single aspect will like impact people and also realizing that there are many different people than you, you using the internet. So like when you're doing things like you're catering to many devices, so it's not only like your huge screen, it could also be a super small screen or a slower computer or slower phone. Someone who has a really bad internet connection, someone who is older, someone who, uh, has a hard time like moving or like clicking on your little label or your little tag people who are less, maybe have less internet literacy, you know, and deserve to get around your application without filling anxiety. And so ultimately, yes, it's about inclusion, but it's also about owning up to what you're saying, because when you see companies claiming, oh, we are user focused, we're user obsessed, right. Ultimately accessibility. And we talking about developer experience, it's all about user experience, uh, knowing your user and, and really caring for the experience of your users, whomever they are. And especially, and including the people that might be a minority, but deserve to have a great experience on the internet.

Kitty Giraudel: 9:50

And, and like more than, sorry, and more, more than a great experience just to begin with an experience at all, which is, you know, not even the case in so many websites, so many centers in so many products, right? Like we're not even talking about going the extra mile. We're going, we're talking about taking the road to begin with, you know?

Sarah Dayan: 10:07

So, um, we, so, so this podcast is around developer experience. And often when, when you talk about developer experience, I've seen some discourse that UX and DX are, can be mutually exclusive. Oh, you are, everybody's focusing on DX. And like, definitely that's a huge buzzword now. Like there would not be this podcast, if it wasn't, you're all focusing on, on developer experience, what about user experience? And that if you are catering too much for developers and their comfort, then you are not catering as much for user experience. And there are concrete examples, the build size is increasing or this, or you are using this framework that makes your life better, but is it better for your users? Uh, maybe, maybe not. And so a term that I've seen a lot is developer convenient. It's like, oh yeah, this is a lot more convenient for developers. So I'd love to know if in, in your opinion, especially because you worked on those open source projects around accessibility, do you think that UX and DX can work together and if they are, and I'm sure they are, what are the, the traps that we need to avoid when we're trying to still the two,

Kitty Giraudel: 11:19

I think one thing that comes to mind, the first thing that comes to mind when we talk about modern tooling, you know, like Java framework, you name it right. Hurting accessibility. One thing that I recall reading on, on Twitter was it's mostly that they made a lot of things significantly easier and more approachable, including interface, design interface building. Right. And if you go back 10 years of, of 15 years building, you know, uh, an interactive component visual component could, could be more complicated, right? It was, it was more difficult. Um, you had more inconsistencies, it was sort of the view and the logic were less tied together. So the were more difficult to build more time consuming to, to build more costly, to build. So people would tend to maybe go more into the, the existing solution. Right. And I, one thing that we've seen with, with the, with the modern tooling and, uh, everything that, that encapsulated with it is it's significantly easier to build those sort of components. Right. Um, it's significantly, uh, faster. And, and because it is, people do build sort of all those, those UI component. They shouldn't be building in a first place because they don't necessarily have the, the experience or the expertise to, to see, okay. But there's more than just me clicking, clicking around on my component than everything works on, on my, in my browser, on my laptop, on Valenti antenna connection and, and so on and so forth. Right. And so it's, it's not so much about modern tooling is hurting facility, is that more people are building more things. And then with that, we, the, the activity knowledge didn't scale at the same, at the same speed, right? So we end up making things way more convenient for everyone to contribute to the web, but we also don't train them in how to do that responsibly. And there is a lot to be said about teaching accessibility or the lack of accessibility teaching in boot camp and studies and any sort of education around web development. So, but I, I think so down the line, that means user experience and developer experience can both work at the same time. Right. And it's, it's gonna depend a lot on the efforts and the knowledge that's put into it. So I think someone or a team that's experiencing implicit design accessibility and building robust components will have no problem having a great developer experience and building great software at the end, right. For the user. But if you have someone that has sort of less knowledge, um, for any reason around what does it mean to build a UI for any sort of people, including people who use different assistive technologies, they will be able to build components just the same way with thanks to all those tools, but they don't really have it. They don't have really have the knowledge to back up, right. So the, the way we can make things easier, uh, or like tap the gap, let's say, I think there will be, we need more educational content on accessible work in general, right? Every stage of the way. So in the design phase, in the implementation phase, in the testing phase and including products my hedge has and so on into the discussion. So it's not one person responsibility. Um, and on the other way, I think, well, in management opensourcing accessible solution or just sharing accessible solution, it doesn't have to be, you just code can be also article blog posts. Podcast is also a good way to sort of, to bring to the, to the front, uh, stage and to tell people, Hey, this is how you can do this, this thing that you, you might have considered building from the ground. This is how you can do it in an inclusive way, in an accessible way.

Bryan Robinson: 14:53

I wonder if there, if there's also something around, like, I feel like user experience, and this is coming from, like I've got years in, in the user experience. World is often honestly viewed as an afterthought is O often, you know, the design teams that really focus on UX have, have to really push for that. And they're pushing specifically for this kind of one flavor of UX, which is the privileged flavor of UX. But I like, I've often, like when, when I've gone to conferences and talked with people, like I kind of push this idea of like radical empathy, the user experience should be as empathetic as possible. I feel like when we're talking about DX as well, we need to be thinking about that too, because I'm a developer and I work on an incredibly powerful MacBook pro. And I remember a decade ago working on an incredibly non-powerful like barely functioning five year old. It was still like a max. So like, Hey, I, I still P in that way, but like, it was an incredibly old computer and it was painful to do everything. And so I, I wonder if there's, if we forget and we lose the empathy and there's a lot of technical education that needs to happen, there's a lot of important things that, uh, having a button as a div is a problem. Like we can hopefully all agree with that. There's a lot of things we can do to teach that, but how do we teach the softer side of it? Like, how do we pull in that focus on empathy and make everyone think before they build, I guess, like we, we say think before you speak, think before you build, but like, how do we center that? I guess,

Kitty Giraudel: 16:28

How do we bring more empathy into the world is a question that is a, it's pretty difficult on its own. As I've read once. I don't know how to reach out to people who think everyone else is a non playable character in their life. You know, ultimately there's the topic of empathy is, is not one we can solve across a 45 minute podcast. I think you touched on an interesting point here, which is how do we, uh, encourage people when they build stuff to about more than just their own perspective, their own experience. And I think one thing we need to be careful of is not to discourage people from building either. The reason we all there is because the web is a very approachable platform. Um, the, our jobs are approachable. We don't need to do 10 years of studies to get to where are in, in life, which is incredibly, uh, lucky and privileged. But the reason the web is way it is today, but good and bad is because it's open, right. People gets to just open their tax editor and, you know, play around, build stuff and put a webpage online. And this is good. This is a good part. We, we shouldn't sort of scare people into doing that cause we, otherwise we're gonna lose that. And we're gonna have people that are scared to get into web development when they shouldn't, right. Or hopefully they, they hopefully they shouldn't, there's definitely a balance to find between telling people, Hey, that at school you wanna build something, let's think this through, let let's discuss what needs to be done. Right. But also not scare them into, you've done 10% of the job. And there's so much that is that you haven't considered that you, that you've already broken, uh, that, that was working natively of things like this. Right? So it's a little tricky. And honestly, I'm not sure how to do that on at the industry level and know how to do that in a company level. Because when you have a team it's significantly easier to manage what's going on because you have a small scope, you have a small sphere of influence, and you can sort of keep things under control. When you have an entire industry with million of professionals, you know, how do you do education at that scale is, and as a, as I said, we are gate keeping, essentially we are at gate keeping the industry and saying, well, you need to know all of this before you get started, because we don't want that. Yeah. This is definitely a tricky and tricky problem solve for sure.

Bryan Robinson: 18:39

How do you do that at the company level? Then I like to think that maybe there's some development team leaders listening to the podcast. How can they start pushing that into, into their companies?

Kitty Giraudel: 18:49

The best thing I found is to hire people who care. I graduated lucky because I joined go as one of the, the first pre engineers. And I joined N 26 as the first web engineer in both companies. I was, uh, I was hired to hire. So I was hired to build a team and to like essentially build the platform and carry things, or like get them started, right. Get, get them off the ground. I mean, it made, it, made it significantly for me to have an impact there, for sure. Ultimately, the thing that are the biggest impact in terms of the accident of the product I've built over the last few years has been hiring and encouraging people to care. One thing that we've done is during the, the technical interview, talking about accessibility, asking what they think it asking if I had any experience asking if I understand it. And now we even at goal as we even pushed it earlier. So I'll, I'll keep it brief here. But what, the way we do hiring is we, we don't ask for a CV. We don't ask for a resume. We ask people to fill a form, six questions, one on feature development, one on HDM, one on CSS, one Java, one accessibility with you. We don't even see their name. We see nothing from them. We only see the form. And one of the questions, flexibility, and we filter hard on this. So if people don't know what it is or keep it very generic, then we just decline the, and this helped a lot, finding people who know at least a bit. So we don't expect to hire only expert, right? It's just not a thing. And we also don't need a team of experts, but we, we want people to at least have a common understanding of what it means, know sort of the basics. Um, know how to ask the right question, know where to, to do some research. The nice side effect of this is that it's usually people who are pretty empathetic. It's usually people who can think of others and people who can work very well in the team. People who care about documenting their work. It's kinda a very nice sort of filter question. The main goal is we wanna make sure people care about xFi and know about it. And the super nice side effect of that versus is that you get a lot of value, orbital value, all of this question alone. And that's really what has been the most effective, honestly, because convincing people, convincing your coworker, that they have to care, rarely works. I mean, ultimately people care about what people care, right? Like you can't change that and you can have conversation and hopefully you can also lead to do their own research and understand white manners. But you know, if someone doesn't really care, there's no good reason for you to magically change the world perspective. Right? So making sure that you get to work with people who care to begin with is a good way to then have productive and fruitful discussion as a team where you can say, we have a big feature coming up, think about activity right now. Um, before we even get started, what do we need to think of, right. Without having to start the whole thing by convincing people around you that they're not the center. They're not the only one.

Sarah Dayan: 21:37

The way I look at things is that I feel that our industry and like not software necessarily, but the web in software is kind of, it's like teenage phase, you know, we're, we're barely out of kindergarten. You know, we're still in, in those teenage years and we're getting more and more maturity, but we're definitely not there yet. And the only way things are going to, to evolve is little by little piece by piece. The only way the status quo is going away is gonna be blocked by block with the, like the care and effort of people who give a about it, to go back quickly on the topic of like tools and stuff. The reason why I asked this question earlier was that to me, it feels like there are a lot of tools that help today. So you built a Ali dialogue and it helps a lot because now I don't have to build one and I can install an esent plugin. You know, I, I have my Firefox tab and, but at some point, yes, it helps. But ultimately it can make me feel that once those tools say green, I'm good. It's done. The accessibility work is out of my way. And that, you know, my only concern should be about removing those buggy warnings from ESLA. It should stop complaining while accessibility, just like it just like anything that, like, it is a responsibility. It is a concern. It is a pillar of what we are doing. It's not just, oh, remove the bugs, uh, remove the warnings, make sure it compiles. No, it is central. And there is no end to it. It's a continuum. It's something that will, you will keep on having to audit. And no, it's not something where you should have all green, all hundred percent. Yeah. Pat yourself on the back, make your leadership happy that they won't be called out on that. It's something that you will have to care for during the entire lifetime of your project. Right. So yeah, that's uh, to, to me, and, and when, when you mention, like, how do you make sure that people care? Like, yes, you don't want to have to say a, you can't put anything out there until it's perfect because there's no such thing. However, like to have really, really good, uh, advocacy inside of a company, but also inside the community, making sure that yes, people can put something out there, but they get feedback that that feedback can be candid yet empathetic and make sure that I would say accessibility cannot becomes cool in a way, you know, like it, I, I, it tends to, like, to me, it feels like accessibility is still seen as that thing that you have to do that kind of a drag, but ultimately there are also, if you try looking at what developers care for and care about, a lot of them care about doing good work. Nobody wants to do a crappy job. Maybe some people do, but most of the time, people, you work with want to do a great job and they, I want their code to be great. They want to make something great. Um, accessibility should be a part of that. Like, you should not consider that your job is done and that what you put out there is great. If it's not accessible, uh, you were mentioning, uh, UI and UX Bryan earlier. And there are a lot of developers, UI developers who care about it, but they really don't know what great UI N UX is. It's not just that it looks good. And we're slowly getting out of that. Like, uh, Kitty y, I know you've been working for like, uh, 10 years or so. So you remember the flash years and we were all about, wow. Like we, I want my, you know, my website to be flashy and making like thunder bolts and stuff like that. And we got out of that. Like, we matured our way out, out of that. And we're making interfaces that are catering, like the overall of interfacing that it's getting better. It's not there yet as far from it, but it's getting better, which is still a hint that people are starting to care that, yeah, well maybe they showed this to, uh, their grandfather or they showed it like somebody called them out and they actually cared. Ultimately, I'm wondering if it's not about also making sure that accessibility is while still being presented for what it is, who it caters for first and foremost, but also making sure that it becomes an inherent part of the training. Just like building a responsive website. There's no way you are building something unresponsive today. And you're going to get a, like, you're not gonna get away with it. There's no way you should get away with a non-existent website.

Kitty Giraudel: 26:29

There's one thing I wanted to come back to, which is we have tools and we start having more and more testing tools for facility. You know, we have a, which is an absolutely fantastic testing suite. We have some integration with Lin, I think most major frameworks now, or like, uh, develop environments now have built in HML accessibility. JSX sort of Lin, which is great. And you are absolutely right. We can't say, well, there's no error. Boom, we're good to go. Right? So this, we need to make it clear or clearer is that there's only so much that we can automate in terms of actually testing. I think this is not quite understood or acknowledged yet as at an industry level too often, as you mentioned, people are like, well, you know, I run it through this center, this center, which is great. They, they do in the first place. Fantastic. But we need to, to make people understand that this would be a minimum, right? And then there's more that they need to essentially educate themselves about and teach themself or learn about, and then test a bit more manually or test we've all, all ask people, ask other users, you know, other people to try it, right? So this is getting better. I get feeling it also, it might also be the thought bubble, but I feel like it's getting better. I feel like for us all, because automation is more, more present overall. People at least learn that it of thing. And then we need to just sort of get the extra step, which is, this is called, you're doing it. And this is great. There's no more warnings, no more errors, but this is just the part of it. You need to understand a bit more. And then this is how people can understand that is the, the w CG, um, standards, right? That, um, there's a lot of content they can read on to a certain extent. You have the exact same discussion at the compliance level, which is, uh, which is usually something we have in companies like this is great that you finally are compliance. What get 2.1 double a amazing, fantastic, good job. But, uh, there is, there's more work to do. There's always more work to do. As you mentioned, Sarah, it's like, it's never done. Like it's not an on, off switch, right. You're not accessible or not accessible. Having also at a company level at a executive level and authority level in, in organization telling we need to reach compliance because well, you, you need to reach compliance as a company, right. Essentially, but then we need to do more work in terms of inclusivity and accessibility and caring for more users or caring for the same users, but better right

Sarah Dayan: 28:58

In the us. I believe that there are some regulations, uh, if you are doing business online, including for, or the private sector, it's not only for the public sector, I'm not a us citizen. And I have no idea to what extent it is. But do you think that it is, it brings like some positive, do you have an opinion on that? It's not the same in every country. We don't have regulations in like the same kind of regulations in France and probably in Europe, although we have of some others. So ultimately once it is a regulation and you can have a fine for that, you have to do it. So there's no way you're not gonna do it. So in a way, you know, it can move the needle faster. And in another way it could say, well, do we have to go to those length to get people to do the right thing? So I, I, I'm interested in your perspective on that.

Kitty Giraudel: 29:50

I, I'm not a legal expert on accessibility. I know I, I know the, the big picture, which is essentially sorry, that in the USS companies are more likely to, uh, face class action lawsuit. If they do not provide their service to essentially everyone, uh, disabled people included. Of course. And again, please, anyone listening do not quote me on this because I am not a legal expert accessibility, but my understanding is that the prime in Europe we have is not so much that we don't have legislation because most countries have some is that we don't enforce them to begin with or very little, and also they are not in most countries applicable to the private sector, which essentially means any company that's not working for a government or government affiliated organization. Don't really have to really, um, care much about it or rather they can, or they cannot, but they're never gonna get a fine point. So that's a bit of a problem, of course, right. Looking back at N 26. So as I mentioned, I, I got hired early on and we hired a lot of great sport engineers and over disciplines to, to work on, on the new, the new platform. And we did a, we did overall, I would say, um, a good job on accessibility. And then we got the by, I knew from leadership three years later when we wanted to launch into the us. And, and I have a, I have a recollection of the head of legal in the us calling me in panic and saying, oh, we have to do things of accessibility. What does it mean? What do we have to do? So at the time, so what, what happened is we, we hire the company to join audit of our web platform. So we audited the signup, weed, the website, weed, the web app, um, and the support center. We audited everything. And, you know, I mean the audit came back and it was not perfect. Like we had 80 or 90 pages of, um, reports and we like solutions and suggestions and recommendations and so on. And then for the new extra weeks, we sort of wrote a bunch of bunch of geo tickets and, uh, assigned it to different teams were responsible for different parts and, you know, sort of trained through the, the bugs and essentially got resolve. Right? So it definitely brought change and it brought a positive change because we always cared about it as, as a team, but we never really had support from executive level or the company or, um, or sometimes of a discipline. And then when, when we had, when we lost your yours, and we sort of had to comply for lack of a better term, right? This is when a lot of discussions became smoother because we didn't really have to do a convincing part because executive leadership just said, we essentially, we need to be accessible because otherwise we're gonna be in trouble in the us. Right. Regulations do help. And the same parallel can be, can be done with mask mandates and vaccine mandates. Like they're tricky to, to, to set up, right. Obviously, um, like if a cell for free comes with like a, a cost to set up this regulation and emotional cost for some people. Right. But, um, it makes a difference because people sort of have to comply and then ultimately you have, you make an impact on, on the group as a whole. Right. So, um, so that, that's certainly something that has, you know, now whether whether to it's a healthy way to say it, you know, it it's something, something else, right. It's, I've always said back in 26, like it's a shame we had to wait for an actual audit for people to, to start meaningfully engaging in the discussion. Right. Um, because it, it, you know, it was a civil rights before that it didn't, it's not, when we decided to launch to the us that it became something relevant, it was always relevant. Just people chose not to care.

Sarah Dayan: 33:24

So I'd love to, to know, because personally, I tend to find that best practices and good practices even tend to work best when they're documented, they're automated. And also they are regularly advocated that you, of people in place who make sure to pass on the knowledge and to pass on the good practices. And so, for example, at Algolia, we are highly concerned with security. That was one of the first big, big hires at Algolia was our, uh, current head of security. And it translates into concrete measures. It's not like, oh yeah, we're, it's like we have a dedicated security team. We don't, we don't outsource that. We have a new trainings, including leadership has to pass the, the, the training. We have clear processes for using whatever, like new services, new programs. We have like a lot of audits. We have a, a lot of compliance standards and stuff like that. The thing is that for some, for many people, they are at the company, they wanna do it. They have no idea how to even get started from your experience, because you've done that at, uh, N 26. How does someone who wants to lay a foundation for, and accessibility driven, maybe not company, but at least maybe web team, how can you get started as a person with great intentions and who really wants to take some concrete actions?

Kitty Giraudel: 34:56

So you, and you touched on it a, a large part of it is gonna be documentation. And that doesn't mean just return documentation. That also means the one you do in con reviews and the one you do informally side by side when you pay on a, on a feature. Right. So, uh, a lot of it is going to be essentially sort of educational content, right? So I'm maybe looking at, go this time because it's, it's a little more recent. And I got a lot of experience from in 26. I joined in January this year and I started working a little bit in December because I was off at that time. And the first thing I did is I wrote a 7,000 word essay on accessibility and what it means to redo the basics essentially. And this goes through some key sort of HTML structures. So like a document outline one H one Lang attributes on HTML, um, elements, um, skip links, you know, in self drillings, buttons, all links and so on and so forth and symantics and so on. But also it went into how to cater for, um, anxiety of people suffering from anxiety, how to involve internalization, how to consider performance as well. So it's like, sort of like, um, high level view of what it means to build like robust and high quality features. Right. And this, we reference it all the time. Like, and not just in engineering, it's essentially the go to sort of document when it comes to anything around accessibility. That's the first thing is like, you, you wanna take it down somewhere because you will always have to explain to new people or to people who are getting interested, what it means, what, how, how is it ized in, in day to day work? And you don't want to go through it just, just, uh, in person every time. Right? So you want to document as much as you can. It's a little organisms, so you want to constantly update like it, you can't write it and then expect it to so, you know, standard test of time. So, so that's, that's important to always work on your documentation, um, and empowering people to do so as well. You also don't want to be the person to document accessibility, right? So you, you want to, everyone to be, to feel involved and concerned, right. And, uh, you wanna tell them if you have a question around accessibility and you, you're not sure how to solve it, let's pair together. Let's find the answer, and then we'll just write the documentation together, or you do it on your own. If you feel comfortable doing that, right. Getting people into mindset where they contribute to knowledge base on accessibility and to, and, and about their culture of accessibility, where, you know, we embed a bit everywhere and they have discussion with designers and with PMs and so on. It's a good way to do it because, and we touched on this earlier, um, it feels less like a chore. It feels less like, ah, you know, I have to make it accessible and I don't know how to do it. Right. And it feels more like just, just part of a job out of what they, they, they need to do to, to do it well. And in many case, what also makes content interesting, personal opinion here, I've been doing that for 10 years. There's only so many ways to write a button, you know, um, if it wasn't for building accessible interfaces and sometimes complex ones, I think I would've just like burnt out bored by now. I encouraging people to see it as like part of the role, but also something interesting, something that just, you know, it's really reaching for high quality is, is a good way to do that. And then the, so part to that would be try to do the work once and not more so build accessible components and base the accessibility in as much as you can. And that goes also for security. And that goes for, for performance, essentially build Robish components, right. Document them, test them, clarify them, write code comments in that, to explain why there's this thing, why this matters, why there's this attribute this prop and so on. Right. And then just Anchorage people to obviously to use them. Right. But also to challenge new implementations, right? You don't want to reimplement like the, the form field 7, 8, 10 times just because it looks different, right? So you want to have a centralized unit and very new. And this is where we get back to developer experience. The new modern technology also enabled componentization way better. Like, uh, react is a good example of it. Uh, react is, is built around the, the, the idea of reasonable components. Um, and if you, if you build robots components and, and resilient and accessible, then you can just essentially reuse them. And you do the work once and you just sort of rip off the benefit everywhere. Right. Which is a good way to approach it. What you really want to avoid is every new feature, every new PR, someone just sort of reinvents the wheel. And when you do the same comment on this, where it's like, please just remember this thing. Right. And they'll fix it, and then you merge it. And then a week later, someone else come in, do the same thing, you know, yet another pattern or yet another form, or, you know, yet another, you name it right. And, or dialogue or whatever. And you say, well, hold on, we, I had this discussion, this changed the comment from last week, right? So this is time consuming. This is, this is costly, just in any sense of the term in terms of time, in terms of money, in terms of energy, in terms of, um, sort of involvement. So you want to reuse as much as you can quality work that you've built, right. And again, not specific to accessibility. Totally, totally the same for any security aspect or any other sort of, uh, web discipline like this. Right. But that's something that essentially has been driving the initiatives in the last, in the last, uh, companies and a good illustration of it was we did the audits at, in 26. A lot of the fixes were actually surprisingly easy, you know, uh, we fixed the component and then we had like 10 pages of audits that, that just went away because it was just the same component. That was a problem everywhere. Right. And it would've been significantly harder to fix if we had implemented it in every single place. Right. Which, you know, goes me not saying, but you'd also be surprised, uh, how much sort of duplication varies on somewhat critical or core logic, which has an impact on accessibility. So really like building reusable components and making sure as for profess, you can, of course, right. But also document because some part of building component can be tricky. It can be contam, or it can be the result of extensive testing with, you know, screen readers, if technology, as you name it, right. You want this knowledge that comes from either you or block post or someone's test or whatever, to leave, like next to the component. Right. What you don't want is to lose it somewhere. And then someone comes to the components, like, why is this, you know, change it. And then all of a sudden you broke something that you clicked six months ago. Right. So really documenting, commenting, clarifying everything within the company. And like, it's the general good advice for credit quality in my personal opinion. Like there's no such thing as too many comments. And I, I think this idea of like self documented code is absolute garbage. Like it's just not a thing.

Sarah Dayan: 41:37

Yeah, definitely. And so yeah, what I'm hearing is that good mix of systems and culture, uh,

Kitty Giraudel: 41:45

Both are necessary. Yeah. For sure. Like you can't carry, it's only. So from systems, cuz again, that comes back to people, not caring and not putting the effort when it's needed people, not having the hard conversation when, when they're necessary. Right. But you also can't carry it just on people's Goodwill. Right. Like you need to build it as part of the system you need, you need to like consider it and, and, and sort of bake it at every step of the process. Right. Um, so it's definitely a, a good, a good summary from you. It's a good mix of culture and system. Yeah.

Sarah Dayan: 42:15

Yeah. And, and there is this quote from, uh, from your blog that I really like, which is, uh, accessibility is not about doing more work, but about doing the right work. And like, yeah, you, you touched on that, uh, earlier, like if you make accessibility, but even tests or security or anything, first class citizen, then it's like, you won't have to painstakingly retrofit it into your work, which is what you think is hard. And like, yes. Uh, like it is work. It is knowledge, it is expertise. It is like mastery, but it is not more work. It is just the right way of doing work. And you, us, like if you build your house with matches, it's gonna be harder to make it robust later on. Definitely. It's not like, but still, uh, like try, try to, uh, to learn things, uh, try to, to get better and accessibility being better at accessibility also being a better frontend developer.

Kitty Giraudel: 43:15

Absolutely. I think the last thing I've been trying to advocate a bit more recently is that, um, accessibility and security should be handled the same in companies. So we, we see companies hiring like security teams and, and in some instances it's absolutely justifying like in many instances, but especially in FinTech and, you know, any sort of, um, sensitive, uh, payment getaway and so on. Absolutely. I think it's more on the way it's considered and prioritized, like companions would pay for penetration testing and audits and so on in security all the time. But then you ask for like, you know, 5,000 euros to do an audits of a part of your application and then listening, it's like, oh, what a budget? You know, it's, it's way too much. Uh, so understanding both topics at the same level, which essentially suffer quality with risks and significant problem down the line, went done wrong, um, is a good way to do this, which also means, and I've, haven't seen, done a lot. Um, having companies hiring at least are not too accessibility expert, which are essentially there to do the groundwork and the educational work and support teams in their effort and so on. Right. And treat it similarly in discussions. Right. So in terms of priority, in terms of care, from the beginning of the project, things like FRA modeling is a great tool. It's a great security tools to make sure you're designing your application correctly. Right. And I think accessibility modeling is also a good way to approach a new feature or new project. And, you know, think about it first before getting into it and then having to, as you mentioned, retrofitted and like pay huge cost into essentially fixing what has been designed poorly to begin with. Right.

Sarah Dayan: 44:56

So we're touching to the end of this show. And, uh, I'd love to, to ask you the traditional question of, uh, of the podcast. Uh, if you can make it maybe a one-liner, but how would you define great DX and is your personal level of expectations?

Kitty Giraudel: 45:14

Junior friendly for me, that's all about this. If I learned anything from the end 26, uh, experience, um, I hired 25 web engineers back then across four years and we hired countless juniors. It needs to be junior friendly. Like it needs to be sort of you entered industry and you, you enter the system and you know, what's going on. Like for me versus this,

Sarah Dayan: 45:36

I love this. Where can people go to find you online?

Kitty Giraudel: 45:39

Uh, so on Twitter at@kittygiraudel or on my website, which is also the same. Um, and when I'm also on GitHub and so on, but you know, it's, it's not the way I post the most

Sarah Dayan: 45:51

Bryan work. Can people go to find you online?

Bryan Robinson: 45:54

Oh, well, you know, you can find me on Twitter@ brob, or, you know, the Algolia official account is where I'm at some as well these days.

Sarah Dayan: 46:03

All right. And you can find me on@ frontstuff_io, which is officially the worst handle on Twitter. Uh, and you can find my work at sarahdayan.com. Kitty thank you so much for chatting with us today. This was a really great conversation. I really loved it. Thank you, Bryan, for co-hosting with me today, listeners, I hope you enjoyed this, the, this new episode that you learn, new things that you want to become the accessibility team master, but also train more people at your company to care and to realize that accessibility is important and is the core it's at least at the core of your discipline. Uh, thanks a lot, uh, for following developer experience and stay tuned for the next episode. This was developer experience, a podcast brought to you by Algolia. You can find this podcast on your favorite podcast platform. We are on Spotify, apple podcast, Google podcast, Pandora, overcast, everywhere. If you want to know more about Algolia check us out on algolia.com and we are at Algolia on Twitter.