Accessibility Credit and How to Pay it

Rate this content

Tech debt comes as free credit for our lack of experience, wrong deadlines or simply a mix of bad decisions; but no matter how it gets there, the cost is usually on accessibility. The first to sacrify is the one tool that allows all people to surf the web without constraints.

How do we tackle a technical debt for accessibility? Where do we begin? How fast and far can we get? In this talk we will go through real-world examples on how to begin fixing the most important technical debt out there.

21 min
20 Jun, 2022


Sign in or register to post your comment.

AI Generated Video Summary

The Talk discusses technical debt and its relationship with bad code and lack of caring. It emphasizes the importance of repaying technical debt, particularly in terms of accessibility. The low number of websites passing basic accessibility tests is highlighted. The Talk provides strategies for repaying accessibility technical debt, promoting accessibility, and incorporating design systems. It emphasizes that accessibility is everyone's responsibility and should not be overlooked.

1. Introduction to Technical Debt

Short description:

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. 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. 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.

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.

2. Understanding Technical Debt

Short description:

But the reality is that there's supposed to be a system to help that junior developer avoid sending bad code to production. Bad code is usually more harmful than technical debt because it shows a lack of caring about the final product. Technical debt is a conscious trade-off, where we choose to gain something immediately in return for paying it back with interest later on. Let's take an example with theming. We made the conscious decision to build a fast solution for a client, even though it resulted in coding garbage. We will fix it later.

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.

3. Repaying Technical Debt and Accessibility

Short description:

So congrats. You have just created your first technical debt. Will you repay? We have two paths: repay or pretend nothing happened. If we repay, we need to clean and build it right. If we pretend, it accumulates interest and makes team members sad. Working with old tech-def code bases hinders learning and limits possibilities. We need to repay, specifically addressing the accessibility part of technical debt. Accessibility is often postponed, resulting in code releases that are not accessible. We can refer to the WebAIM report for an annual accessibility audit.

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.

4. Accessibility Test Results

Short description:

In 2022, only 3.2 websites passed the basic accessibility tests, which is a slight improvement from the previous year's 2.6. The most common errors include the lack of alternative text for images, compliance, color contrast, labels for inputs, document language attributes, buttons, and links.

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.

5. Repaying Accessibility Technical Debt

Short description:

Many websites still have accessibility issues, such as marquee tabs and blinking content. Lack of accessibility is often a conscious tradeoff due to deadline pressures. To repay accessibility technical debt, start with a basic audit using tools like WAVE or Axe. Create specific tasks to address issues incrementally, fixing bugs, rebuilding broken components, and adding new features. Document unresolved issues and put them in the backlog to acknowledge and empower the team. Avoid creating more issues by learning from mistakes and implementing a long-term plan for cultural change.

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.

6. Promoting Accessibility and Design Systems

Short description:

What we need to do is find people who care, speak about accessibility in meetings, let people know it's important, and get COs, CTOs, and managers to care as well. We should update processes, build automated tests, and do more manual testing. Run keyboard navigation on features, work with QA/QE to check for accessibility, and include accessibility in internal demos. Design systems are the key to fixing accessibility issues everywhere. Follow Brad Frost and Sheena Ann for practical information. Hire frontend developers to ensure accessibility is fixed correctly. Remember, no code can fix bad design.

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.

7. Design Accessibility and Responsibility

Short description:

If the design is inaccessible, so is the website. Bad UX flows cannot be fixed with code. We work in a team with developers, designers, product managers, and project managers. Accessibility is everyone's responsibility. Avoid technical debt, but don't burden users with disabilities.

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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TestJS Summit 2021TestJS Summit 2021
30 min
Configuring Axe Accessibility Tests
Axe-core is a popular accessibility testing engine that is used Google, Microsoft, and hundreds of other companies to ensure that their websites are accessible. Axe-core can even integrate into many popular testing frameworks, tools, and IDEs. In this advanced session, we'll be learning how to configure axe and its integrations to fine tune how it runs and checks your pages and code for accessibility violations.

JSNation 2022JSNation 2022
24 min
a11y and TDD: A Perfect Match
Accessibility has been web development's ugly duckling for quite some time now. I often get asked, "when should you test for a11y in your apps?" My answer is simple, "right from the start!". Regardless of the framework considered - React, Svelte, Vue, YourOwn™️ - as developers we are in a privileged position to help the ugly duckling grow into a beautiful swan. How? By diving deep into the pond and harnessing the power of Javascript APIs to build the right components for your web apps. And how can do you know you are building them right? By pairing Test Driven Development with the Testing Library family. Ready to grow your web apps into swans?
React Advanced Conference 2021React Advanced Conference 2021
32 min
How to do Good Without Doing Anything
There’s no arguing that building accessible websites is a force for good. But ensuring that our React websites and apps work for everyone can be time-consuming and isn’t always easy to get right. Luckily, investing a little bit of time on your accessibility workflow and setting up a series of automated tools will end up saving you tons of time and energy in the long run.
In this talk I will demonstrate how you can leverage automated tools, clearly documented code standards and a well-defined development process in order to make building and testing accessible React apps a breeze. I will discuss the ways that I automate certain aspects of my development workflows to catch accessibility errors, define and set up tests and go through the entire lifecycle of accessibility feature development using a real-world example.

React Summit Remote Edition 2021React Summit Remote Edition 2021
34 min
Building Accessible React Components
With the growing community and great tutorials, it's fairly easy nowadays to start building web applications with React. However, the vital aspect of accessibility is often missing which leads to web applications creating exclusions. Nothing in React prevents us from building accessible web experiences, but we need to learn to harness its power in the right way while dealing with some unique challenges caused creating web pages with JavaScript. This talk will focus on how to solve these issues in the context of React. It'll also emphasis why it is important to build accessible web apps. In the end, I will also share some cool stuff and tools in order to make your web app more accessible.

JSNation 2023JSNation 2023
30 min
Accessible Component System Through Customization
Most current UI libraries provide great user experience with a vast of components. But when it comes to heavy customization, and non-standard scenarios, especially for E-Commerce, they become hard to manage, scale or even slow down performance.
How to create a UI library that provides users the most possible freedom in customizing components, while keeping our performance and scalability to the fullest? How much accessible we can provide out of the box to our users? How much customization freedom is enough?
That's what my talk's about.

Workshops on related topic

React Summit 2023React Summit 2023
109 min
Web Accessibility for Ninjas: A Practical Approach for Creating Accessible Web Applications
In this hands-on workshop, we’ll equip you with the tools and techniques you need to create accessible web applications. We’ll explore the principles of inclusive design and learn how to test our websites using assistive technology to ensure that they work for everyone.
We’ll cover topics such as semantic markup, ARIA roles, accessible forms, and navigation, and then dive into coding exercises where you’ll get to apply what you’ve learned. We’ll use automated testing tools to validate our work and ensure that we meet accessibility standards.
By the end of this workshop, you’ll be equipped with the knowledge and skills to create accessible websites that work for everyone, and you’ll have hands-on experience using the latest techniques and tools for inclusive design and testing. Join us for this awesome coding workshop and become a ninja in web accessibility and inclusive design!
TestJS Summit 2021TestJS Summit 2021
85 min
Automated accessibility testing with jest-axe and Lighthouse CI
Do your automated tests include a11y checks? This workshop will cover how to get started with jest-axe to detect code-based accessibility violations, and Lighthouse CI to validate the accessibility of fully rendered pages. No amount of automated tests can replace manual accessibility testing, but these checks will make sure that your manual testers aren't doing more work than they need to.

React Summit 2022React Summit 2022
161 min
Web Accessibility in JavaScript Apps
Often we see JavaScript damaging the accessibility of a website. In this workshop, you’ll learn how to avoid common mistakes and how to use JS in your favor to actually enhance the accessibility of your web apps!
In this workshop we’ll explore multiple real-world examples with accessibility no-nos, and you'll learn how to make them work for people using a mouse or a keyboard. You’ll also learn how screen readers are used, and I'll show you that there's no reason to be afraid of using one!
Join me and let me show you how accessibility doesn't limit your solutions or skills. On the contrary, it will make them more inclusive!
By the end, you will:
- Understand WCAG principles and how they're organized
- Know common cases where JavaScript is essential to accessibility
- Create inclusive links, buttons and toggleble elements
- Use live regions for errors and loading states
- Integrate accessibility into your team workflow right away
- Realize that creating accessible websites isn’t as hard as it sounds ;)
React Summit Remote Edition 2021React Summit Remote Edition 2021
91 min
Creating Accessible React Native Apps
React Native is a framework used to create native iOS and Android apps in a way web developers may already be familiar with. But how do you ensure your React Native apps are inclusive and usable everyone? Scott will share tips on how to test and build React Native apps with accessibility baked-in!