Hi, I'm Eva. I'm here to speak about
accessibility credit and how to pay for it. I'm a
frontend developer currently working at a company called Mayfell. I'm also the organizer of CSSConf Argentina. And I really much enjoy working with, you know,
design systems,
accessibility, and very useless
animations just like the one you see here. I'm here today to speak about technical depth. Most of the time when I think about technical depth in my mind, this meme comes to the front of my head. It's kind of these situations where you have to deliver something and the whole office is on fire, and you have to deliver anyway. So, you just try your best while pretending that nothing is burning, nothing is on fire, and everything is okay. So, I do believe that we use memes as a coping mechanism, especially for technical depth. So, here are my favorites. Just put the technical depth on my credit card. Moving fast and breaking things. Fragile development guide. I don't understand why it takes so long to build a new window. And one of my favorite ones. Let's fix this with a temporary solution. But that will create more problems in the long run. Yes. We will have chain shops by then. So, it's not tech depth if you're not around when it gets fixed. Or what I actually enjoy saying is it's not tech depth if you're not around when it begins to cause trouble. Because having tech depth is normal. The problem comes when it begins to cause issues in the development process. So, what is technical depth? What isn't technical depth? Is bad code technical depth? Well, in my humble opinion, bad code is not technical depth. It's actually a lack. It's a lack of knowledge, it's a lack of caring, and it's a lack of quality control. Most of the time, it means that someone doesn't care about what gets sent to production. It's very common to just blame the poor junior developer that just joined the company because they sent bad code to production. But the reality is that there's supposed to be a system to help that junior developer avoid sending bad code to production. There's supposed to be a manager and fellow developers that should be able to help this person to avoid it. I honestly believe that bad code is usually more harmful than technical depth, mostly because it shows this lack of caring about the final product. And mostly because it ends up being kind of this sad place where they blame junior developers for just sending ugly code into production when it shouldn't be like that. So, what is technical depth, then, if it is not bad code? Well, technical depth is a very conscious trade-off. And that is, I think, the most important part when we speak about technical depth. It's that it is conscious. It's something that we do consciously. There's a quote that I really enjoy about technical depth. It says, it happens when we choose to gain something otherwise unattainable immediately in return for paying it back with interest later on. This is a quote by Mr. Howard Roberts. If you don't follow him on Twitter, I highly recommend you to do so. He speaks a lot about refactoring and technical depth. So, he's extremely kind human being, but also he's extremely knowledgeable. So, if you do go find him on YouTube, you will definitely learn a lot. So, if we look at this quote, it says otherwise unattainable immediately and paying it back. Those are the two things that we need to take into account when we speak about technical depth. Let's take an example. Let's talk about theming. Let's pretend we are a company that provides a service to different clients and our clients use our service and our service cannot be branded. It doesn't have any theming. It's just this color and that's it. And we have a possible client, a huge client that says, if you provide theming that looks like my branded colors, then I will be your client. So, what happens in those situations is that usually the project manager or the product manager goes to speak with the development team and says, okay, what's the estimate to make theming happen? And the developers might say, well, a couple of weeks, perhaps four or five weeks if we want to do it right. That would mean that we will lose the client and we wouldn't want to do that. So, we end up saying, okay, well, I can build a very fast solution just for this client, just so we don't lose it. In four or five days, how does that sound? That sounds good. That's great. So, we build the thing. We import all the things and it works and we got the client and that's great. And we just coded garbage. But you should be very proud of it because that's amazing. We had very good reasons to create that. We made the conscious decision of saying, I'm going to build ugly code in exchange for getting a client and then I'm going to fix it. So, congrats. You have just created your first technical depth. Now, comes the second part. Will you repay? So, we have two different paths. We can either repay or we can pretend nothing happened. If we do repay, that means that we need to take some time to sit down and clean what we did and build it right and build it for future clients as well. And if we pretend, then that means that we keep on working with whatever we were working before this and never actually fix those importance. And what might happen is that it will accumulate interest and it will also create a very much like a snowball effect. So, that means that perhaps another client comes in and says, hey, that client has theming. I want theming too. And then you will have to do all those importance again just for this client B and your code is getting worse. And then client C comes and you say, well, okay, I'm going to put more importance in it. And it gets worse and worse and worse all the time. Because if you don't pay, it will accumulate interest. And it will also make team members sad. I don't know about you, but I have worked with very old and very tech that feel code bases before. And it's not a very happy situation. You feel like you are not learning. You cannot try new things. It's not just developers being sad. It's also like product managers and designers when they realize that what they want to build is not possible. So, we need to repay. And how do we repay? Well, I'm going to specifically talk about repaying the
accessibility part of technical debt. And you say, what? Wait. Is
accessibility technical debt? No. I mean, no it shouldn't be, but it actually is. The reality is that
accessibility users are usually considered second hand citizens of the web. So, usually they are postponed for the future in spite of their needs. And what usually ends up happening is that we end up releasing code that is not accessible because we want to release it on a very tight deadline. We can take a look at WebAIM report. They do a report, an annual report on
accessibility on the first one million homepages of the web. And they run a very basic audit for
accessibility with WCHE tests. And they check for alternative text, good contrast, labels for inputs, document language attributes, and what's on something with this text. So, they did check for very simple things that they can be automated. And they figured out each year how many of those one million web pages pass those very basic tests. And I ask you to think right now, how many do you think that pass those tests? Is it at least 20% of those? Is it at least 10%? Or is it like at least 5%? And the answer to that is in 2022, it was only 3.2%. So, only 3.2% websites passed that test. It's a little bit better than last year. Last year it was only 2.6%. So, I guess we can be a little bit happy about it, but not too much. And the most common errors are those. The lack of alternative text for images, lack of compliance, color contrast, lack of labels for inputs, document language attributes, and discernible text in buttons and links. Many of those things are usually fixed with like one line of code. There's also a fun fact that I always enjoy to mention. Despite being 2022, 9,152 homepages had a marquee tag, which many of you might be too young to know what it was. 373 homepages had blinking content. And that shouldn't happen in 2022. So, why does this happen? Well, it's the situation of lack of
accessibility is more often than not a conscious tradeoff. We don't test for
accessibility and we just release whatever feature we are working on without doing proper
testing because we want to, you know, meet the deadline and the deadline didn't take into account people with disabilities. So, how do we begin repaying? So, we have two things to bear in mind when we want to repay
accessibility technical debt. First thing is how do we pay the current technical debt? And the second thing is how do we avoid this happening again? Which is a very long term process. So, for the current technical debt, I highly recommend to run a very basic audit. You can use Wave or Axe or any automated tool that checks for the most common errors and write them down. And trying to find some spare time to improve it slowly. Because you might find yourself with like 600 issues. And it's like, oh, my God, what do I do? Well, create a small and well defined task. Like the outlines of these elements are not working. Like this drop down menu doesn't appear on keyboard navigation. Create very specific well defined tasks so that you can work on perhaps 15% of each sprint. That means that it will take you a long time to fix it. But that's okay. Because you are doing work to improve it. So, you fix bugs. You rebuild broken components. And you also perhaps build new features that you didn't have before. Like an escape navigation link. And when you don't have the time to fix something, you still document it. You still create a ticket for it. And put it in the backlog. And I know how that sounds and I know what comes to your mind right now is this meme. Which means put it in the backlog so we can fix it later, right? And it's very common to think about this when we say put it in the backlog. Because it does feel like we are never going to fix it. But the reality is that it's not really about that. It's about the fact that we cannot repay what we don't acknowledge. And it's not all about you. So, it's like, okay, I know I have that
accessibility issue. But it's not just about what I know. It's important that everybody on the team knows that I have or that we have this
accessibility issue. So, when we speak about putting it in the backlog, what we mean is we need to empower everybody and we need for everybody to be on the same page and know what are the
accessibility issues that we have and that we haven't fixed yet. So, that is why we put it in the backlog. In order to acknowledge that we still have a lot to do. And then we avoid creating more. Which is the fun part. Because we got to a situation where we suddenly have 600 perhaps issues on a single page. So, what we want to do is not just fix that, but also learn from our mistakes and make sure that we don't create the same issue again. So, what we do is we kind of have a plan for a long term fix in order to avoid doing the same mistake again. It all begins with some cultural change in the company. Which is the hardest to get. What we need to do is we need to find people who care. We need to speak about
accessibility meetings. We need to let people know that that is important. And we need CEOs, CTOs, managers to care about that as well in order for us developers to have the time to actually work on it. And also to find the time to update the processes that are not working correctly. Perhaps we can begin building automated tests and put them into our CI and CD tools. Perhaps we should also begin doing more manual
testing. So, if you are a developer, run a keyboard navigation on the feature you are working on just to make sure that a user who has mobility issues or the user is in a screen reader can use the feature you are building. Or we can also work with the QA or QE people and also help them build a process to check for
accessibility as well. Something else that I found that was very interesting that helped to bring the idea of
accessibility into the company was to include it into internal demos. At my previous company, we used to do a lot of demos for new features that we were working on. And we began doing those demos with keyboard navigations and with the screen readers as well. And that might sound a little bit strange, but the aim of that was to show that that is part of our job. We developers, designers, we build products for everyone. So, we should test for everyone. And in order to make more people care about that and know about that, including it in the demos that your company runs is a very good way. And the most beautiful thing in the world that will help you fix
accessibility issues for once and for all is
design systems.
design systems are this single source of truth where you build a component and many different products use that component. So, that means if you do it right once, it works right everywhere. That is amazing. That means fix
accessibility in your
design system. And it will be automatically fixed in all other products that are using that
design system. Do whatever Brad Frost and Sheena Ann said. Because those are two very smart people that work a lot on
accessibility. So, I highly recommend you to Google them and follow them on Twitter and watch their YouTube videos because they share a lot of practical information about that. Another thing that will help you get to almost no
accessibility issues is to hire
frontend developers. And yeah, I mean that.
accessibility is mostly a
frontend issue. So, that means that if you want to have it fixed the right way, you need
frontend developers. And I know that perhaps we feel like we need to save money or have, you know, these people that know everything. And it's great to have a few full stack developers. But if you really want to get this right, you need to find people who specialize in
accessibility responsive and
performance websites. You need to find people who specialize in
frontend. And bear in mind that no code can fix bad
design. If the
design is inaccessible, so is the website. So, if there are bad UX flows, there's no way I can add code that. There's no way I can improve this
design with neomorphism or this one. There's really no way you can add code. Bad
design or bad decisions. It's important to remember that this is not 1999. We work in a team. We have developers, designers, product managers, project managers. We have quality people who check what we do. And it's important to know that
accessibility is not just one person's work, but it's everybody's. It's everybody's responsibility as well. So, remember that you cannot really avoid technical debt. That is not what we want to do. But we can avoid putting the burden on users with disabilities. So, thank you very much.
