Accessibility Credit and How to Pay it

Hi, I'm Meba. 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 debt. Most of the time when I think about technical debt, 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 the 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 that will create more problems in the long run. Yes. We will have to change 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 has 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 dev, 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 dev than if it is not bad code? Well, technical dev is a very conscious trade-off. And that is, I think, the most important part when we speak about technical dev, is that it is conscious. It's something that we do consciously. There's a quote that I really enjoy about technical dev, 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. Harold Roberts. If you don't follow him on Twitter, I highly recommend you to do so. He speaks a lot about refactoring and technical dev. So he's extremely, he's extremely kind human being, but also he's extremely knowledgeable. So if you do go find him in 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 debt.

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. And in four or five days, how does that sound? That sounds good. That's great. So we built the thing, we imported 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 debt. 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 fixed those importance.

And what might happen is that it will accumulate interest. And you 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-def field code bases before. And it's not a very happy situation. You feel like you are not learning. You cannot try new things, and it's not just developers being sad. It's also 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 WCAG tests.

And they check for alternative text, good contrast, labels for inputs, document language attributes. 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 passed 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. Is 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. The most common errors are those, the lack of alternative text for images, lack of compliance, color contrast, lack of label for inputs, document language attributes, and buttons and links.

Many of those things are usually fixed with 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 tab, 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 a situation of, you know, 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 they do? Well, create a small and well-defined task, like the outlines of these elements are not working, like this dropdown 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 go through 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 culture 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 in meetings. We need to let people know that that is important. And we need COs, 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 uses 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 and 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 uses that component. That means if you do it right once, it works right everywhere. That is amazing. That means fixed 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. Very smart people that work a lot on accessibility. I highly recommend you to Google them, 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 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 and it's everybody's responsibility as well.

So remember that you cannot really avoid technical depth. That is not what we want to do. But we can avoid putting the burden on users with disabilities.