Understanding Color Contrast for Accessibility

Captions provided by White Coat Captioning (https://whitecoatcaptioning.com/). Communication Access Realtime Translation (CART) is provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.

JASON: Hello, everyone, and welcome to another episode of Learn With Jason. This is episode number seven for the week. We are just making it a marathon. Today we're welcoming to the show Todd Libby. Thank you so much for hanging out with us today.

TODD: Thanks, Jason, for having me. It's awesome to be here.

JASON: Yeah, I'm super excited. Today we're playing it risky because Todd found out this morning that his internet provider is doing some work in the area. So we're hotspot streaming. Everybody, be patient. We might have streaming issues, but we're going to try to get through this anyways. Todd, for folks who aren't familiar with you or who only know you for eating lobster rolls bigger than your entire self, do you want to give us a little background?

TODD: Yeah, I have been tinkering with technology since I was 9 and learned basic on a Commodore 64. But I started with basic HTML, CSS, JavaScript and went on to PHP Pearl, all that good stuff way back in the day. Now I am an accessibility engineer at WebstaurantStore. So I've been doing accessibility for over 20 years. And yeah, just trying to make the world more inclusive and more accessible for people.

JASON: I love that. I think it's -- and so, accessibility is something we've covered on the show. A few times we've brought on folks like -- you know, we've had Lindsay, Marcy Sutton. We're always kind of looking into how do we make this more accessible to more people. How do we make the things that we build actually include everyone. I think that something that is always interesting to me when you talk about accessibility is that you can feel -- I feel like when I first started learning about accessibility, the way that it felt at first was, like, accessibility was like building a second website for people who couldn't use the website that I'd built. The amount of work that felt like was a lot. And it was very overwhelming. I was very intimidated, and I was like, I don't even know how -- you know, how does somebody use the web if they can't see well or if they can't hear or things like that? And I just started, like, panicking. It let to paralysis. I was like, okay, I had decision paralysis, I knew I needed to do something. It felt like there was too much to do. So I panicked and did nothing. Over time, it's felt like maybe I was overreacting a little bit. Maybe it's not actually two websites. So in your experience, what is the impact of accessibility, not just on people who, like, we would think of as needs accessibility, someone who's legally blind or hearing impaired, but how does accessibility impact all of us?

TODD: Well, that's a good question. So thinking from an organizational standpoint, from the top down, companies don't get sued, unless they're using an accessibility overlay, which I don't know if we're going to touch on that today. A lot of people have probably seen that argument on Twitter a lot lately. But anyway, from an organizational standpoint, stakeholders, you don't get sued. Working with teams and managers, it makes life so much easier to bring in accessibility from the very start. Less stress on your designers, developers, less money spent working, less time spent working. Because when you're doing semantic markup and doing progressive enhancement from the very beginning and using all those things that make things accessible, you don't have to go back and redo it. You don't have to spend that extra time, that extra money. People don't have to get stressed out about it. They don't have to work 60 hours a week, you know. It just makes things better, not only for the users, but the people working on it. Basically for everybody. So when you're making an accessible product, that translates to somebody in a rural area who's still using a 3G connection, and they can look at your website, they can buy whatever off your website. Let's say lobster rolls, off the top of my head, for instance. And you know, it's accessible. It has an impact on everybody, and a lot of people are surprised that it has an impact on everybody.

JASON: Yeah. Well, you know, today, you're on a hotspot. There are going to be websites that straight up will not work on your hotspot because they're too big, too slow. You know, they're just not designed for a low bandwidth connection. You know, we don't think about that, but one of the words that I've heard or a phrase that I heard that really hit home for me was this idea of being situationally disabled. And that accessibility features aren't necessarily only for people who have what you might consider to be a permanent disability, like being visually impaired, but that sometimes someone needs to be able to use a door while holding a toddler. Situationally, they only have one hand available to them. Today, you don't have access to high-bandwidth internet. So situationally, today, you are on a lower bandwidth internet. If I get on a train and I'm trying to check something on the internet and I go through a tunnel, suddenly I have one bar and I can't get really any signal at all. Again, situationally. All of those things are accessibility concerns. And like you said, if we build things to be semantic, if we build things to kind of focus on how do we make sure that if most of the features on the site don't work, you turn off JavaScript, something times out, all those things happen, how do we make sure that experience still works, that people can get done the things they need to get done? And when I started thinking that way, when I was like, okay, if I just write this as, like, if I turn off styles and I turn off JavaScript, is this site still useful? What I found was just by thinking about my mark-up that way, suddenly I had accomplished a huge amount of the things that would have been considered, like, accessibility retrofitting had I not thought about it that way and started putting divs on a page and making them look like the design. Reframing it that way, like, okay, what happens when somebody needs to use this website on the train? What happens when somebody has a really dim display? You know, we're talking about color contrast today. I think that's a very, like -- a lot of times I turn the brightness down on my displays so that I don't get a reflection in my glasses when I'm on video. That means if I go to a site that has low contrast, I straight-up can't read it. A lot of times I won't see text is there because the brightness on my display is 20% or something. Not things you would maybe consider to be accessibility features, but that's how I access the web. I access the web with a really dim display. Have I ever heard of contact lenses? The glasses are part of my personality now. I don't even know what I would do. No one even recognizes me. It's like the Clark Kent/Superman thing.

TODD: I know what you're talking about. I get migraine headaches often. I'm always using dark mode. I know the feeling. I can go to a website that uses animation or motion, and because of the vestibular -- you know, if it's not accessible, if the animation is too fast -- parallax scrolling especially. It can trigger a migraine headache. A lot of testing, from what I've found, is the key to make sure that your product works on something like my phone or even a 2G or a 3G. Now even 4G, you know. A lot of testing. A lot of testing with people with disabilities. There are places that specialize in that. One I can think of off the top of my head is called Fable.

JASON: Okay.

TODD: And for developers, it's making sure that, you know, the product you're putting out can be used by somebody that's having problems like I am today. I want to use your app, but for whatever reason, you know, the cable company decided to work on my internet today, and I got to use my phone as a hotspot. So I want to use your app. Can you please make sure that it can work sufficiently with that decreased connectivity that I have.

JASON: Yeah, and so today we wanted to focus on -- well, actually, you said something interesting about color contrast. I don't want to take that moment from you. So tell everybody what you told me before this call about color contrast.

TODD: You're going to have to remind me.

JASON: You were talking about that report.

TODD: Oh, yes, yes. The WebAIM Million report. It's a report of the top 1 million websites and their homepages. WebAIM, the organization, they test those websites for accessibility. 86.3%, I think it is this year, which is, I believe --

JASON: A lot.

TODD: It's a lot. It's a lot.

JASON: Too many.

TODD: It's a lot, yeah. So that averaged out to be -- I think they found 56 million issues with these homepages. It averaged out to be 56 issues per homepage, which is, again, a lot. Color contrast being the number one reason. I think it's very -- you're losing a potential of one-quarter of the population in this country and between 15% and 20% worldwide as an audience if you're not making things accessible. That's pretty much the bottom line.

JASON: Yeah, and contrast is one of those things that can be very tricky, right. If you have, you know, 20/20 vision, like something that seems perfectly clear to you is completely invisible to me on my dim screen. Right. So one of the things that I'm really interested in talking to you about today, Todd, is how do we catch that? You know, when I was younger, I didn't -- it was hard for me to gauge when contrast was wrong. I only knew kind of by -- it was like this sort of group-think knowledge of, yeah, I'd kind of heard around the community we need contrast to be good. And what people had told me is, well, squint at the screen. If you can still see there's text and a background, then contrast is fine. I was like, okay, that's probably good enough. Right. I would do that at all my screens. But I was still shipping stuff that was undercontrasted. So what I'd love to dig into today is just kind of how do we -- how can we be sure we're doing this right? How can we do it in a way that's not, like, you know, like you said, we shouldn't be doing rework. So not how do I take a design and redo the design with contrast in mind, but how do we think about this from conception through development through shipping so that we're just getting it right the first time and never shipping something that needs to be redone for fixing contrast and things like that. So it might make sense, actually, to start looking at a screen here so we can share some tools and stuff. So let me switch us over into pair programming view. Before we get started, here's that WebAIM report. I dropped it in the chat. I'm going to link one more time. So before we get too far in, let's do a quick shout out. We've got live captioning happening on this show, like we do on every show. That's provided By White Coat Captioning. That's Rachel here today doing the captioning. That's made possible through the support of our sponsors, Netlify, Fauna, and Auth0, all kicking in to make this show more accessible to more people. I appreciate it a lot. It makes my heart warm, and I'm very appreciative that they're willing to do that. And today we have Todd Libby on the show. So make sure you go and give Todd a follow. We're talking about lobster rolls a lot today. You may have seen some lobsters in the chat. I'm just going to see if I can find -- let's see how long it takes to find a picture of a lobster roll in Todd's media history.

TODD: It's been a while.

JASON: I don't know. I bet we're going to find one in the next few.

TODD: More than likely. There's a lot of Arizona pictures right there, now that I'm out in Arizona.

JASON: Was that one? Nope, tacos. Donuts.

TODD: Donuts, yep. Oh, there's one right there, of course.

JASON: There we go. So Todd is a, what, competitive lobster roll eating champion at this point? (Laughter)

TODD: Should be, but I'm not, no. I like those food challenge, and I've done a few of them. Yeah, the food guy in me. I used to work in restaurants a lot, on the line. So, you know, it's another thing.

JASON: I feel like that's a conversation for another day. I also used to work the line. But yeah -- so, okay. I'm very much going on a tangent here. I apologize. What is the -- what is your current personal record for largest lobster roll consumed?

TODD: Um, it's way down in that timeline of mine. But I ate 2 3/4 -- well, no. 1 3/4 lobster rolls. The lobster rolls were two feet long. Each lobster roll had 5.25 pounds of lobster meat.

JASON: I'm sorry. Okay. So roughly nine pounds of lobster roll in one sitting?

TODD: Yes.

JASON: Oh, my goodness. (Laughter) I -- like, yesterday, I had a whole burrito and I was pretty uncomfortable afterwards. I don't envy you the heartburn after nine pounds of lobster roll.

TODD: That was a long car ride home, and I wasn't driving, so I got to take a nap. So that was the best nap I've probably ever had in a car.

JASON: (Laughter) I love it. I love it. Okay. So let's talk a little bit about contrast. Maybe one of the first things we can do is let's just see how does one even measure this on the web? What's a good tool that I can use if I want to see how contrast is on a given website?

TODD: I would go to -- let me pull it up here. I want to say contrastchecker.com.

JASON: There's a WebAIM contrast checker. Is that the one?

TODD: We can use that as an example. There are so many out there. Yeah, why don't we use this one. This one is a good one too. So if you scroll down into that area -- is that actually a working one? I hope it is.

JASON: I think it is, yeah. As we make the text lighter, we can see that we're now failing. And you can see this happen, too. This is where design sensibility can clash a little bit with usability because someone is like, well, I want it to be subtle. This is not important text. I don't want it to be whatever. You can also see here it's not the same threshold for different sizes. So this is still pretty light, and it passes AA. But it's not passing for smaller text. And here we go. Okay. Now we're getting closer. And if we wanted to use it for small text, there we go. Now this is finally high enough contrast to pass on smaller text. But that all changes with the backgrounds too. As soon as the background is a gray color, now the rules are different.

TODD: Yes.

JASON: But yeah, I think I've been on websites where this sort of thing happens. The text is -- you know, somebody didn't think about it and they put a link on the default styles. I can't read that now. That's not working for me.

TODD: So the differences here are normal text is 4.5:1 ratio. So the current scoring system -- and it's a little difficult to explain, going into a new scoring system, which is still down the road. But 4.5:1 is the contrast ratio for text that is -- or, they go by -- this is how old the scoring system is using measurement. 18-point font.

JASON: Point.

TODD: Be that as it is, it's 4.5:1. Large text is 3:1. Graphical, that's 3:1 and that measures adjacent colors to the user interface component.

JASON: You can see here this is pretty -- and so what is the difference between AA and AAA? It feels -- so there's a part of me that always wants to see all the tests pass. So there's part of me that looks at this and goes, okay, I'm always going to go 7:1. I guess the question that I have is, is there a reason that you wouldn't? Like, what's the delineation between AAA and AA?

TODD: It's a very, I want to say, gray area. So me, anyway. Ask a hundred accessibility, you know, people that question, you're going to get a hundred different answers. But whatever threshold they had between AA and AAA, and even A to AA, was -- and I'd have to look back at the WCAG guidelines. I believe it was the hue. Now, I could be wrong. But I think it was the hue and the contrast between the foreground and background color.

JASON: Okay.

TODD: So as far as how far you should go, there's different thoughts on this. My thought is -- and I see it a lot, that people go 4.5:1 and say, yeah, go a little over. To use an example. That's good. That does meet the requirement for AA. And we'll get to the vision simulator later. That really couldn't be inclusive to everybody. Somebody with protanopia or one of the vision deficiencies. Basically, I've learned through being in the W3C and talking with a lot of brilliant people over there, it's not -- color contrast isn't how contrast is between foreground and background color. It's how our brain perceives those colors. So that's where I mention the new guideline, the new scoring system for 3.0, which is again still far down the road. That comes into play. That said, making contrast work is very important these days. I'll tell somebody, go 5:1, go 6:1. Try to get that 7:1. So white text on black background is a 21:1 ratio. That's as far as you can get. You don't want to do that because there's always that chance that somebody can see that, and it'll be all blurry. Give it the squint test. That's a perfect example, and you touched on that earlier. That's the perfect example of giving that a look and squinting at it and saying, nope, can't see it. I do that all the time. I have perfect eyesight, using the term loosely.

JASON: I mean, yeah, I'm kind of in the same boat. I wear glasses, but in terms of passing a 20/20 vision test, like, yeah, I do okay. But I still, you know, at night get light halos around things. That's one of the reasons that computers give me trouble sometimes. Light halos are kind of a problem. I love that you brought this up, that the solution to contrast is not to go as hard as possible. Like, this is actually harder to read for me than something that sits around here. This is kind of softer on the eyes and makes it a little easier. You know, you put a little bit of color in the background to soften this up, and you have a much nicer, easy on the eyes reading experience, versus something really harsh. Like bam, it punches you right in the eyeball. We don't want that.

TODD: Yeah, so a good example for me is if you make the background -- let's see. What is the color code? Can you get the color swatch? Yeah, there you go. If you do yellow.

JASON: Yellow.

TODD: That's good. And you do a white text, I ran into this problem on a form that had this as the -- so I signed up for the newsletter, and this came back to me with a message. I can't read that. I don't know about you. I don't know about anybody in the chat. I can't read that.

JASON: Having trouble with this, for sure. That is pretty rough. Yeah, and you know, I found myself, as I've gotten older, this has gotten harder for me. So a lot of times, I have to select the text, but you can see here that this is not -- this doesn't make a whole lot of helpful difference because of the text selection color. So, you know, worst-case scenario, in a few rare circumstances I find myself opening dev tools so I can edit the color of something so I can actually read it. That is not an option that's afforded to the majority of people because opening the dev tools and changing the way a website works is not a thing that they care to do or necessarily know how to do. So they'll just leave and go somewhere else. Assuming they have the option, of course.

TODD: Yes, and that's how I got into accessibility because I know people -- friends, family -- that have visual issues. I have another couple family members with other disabilities as well. Seeing the frustration on their face when they come into something or they run into something on the web that's inaccessible and seeing the frustration, that look of I'm just going to give up, I don't want to do this anymore because it's inaccessible. That is what lit the fire underneath me to jump on the accessibility train. And if people, I think, saw that -- and there's a lot of people that probably do, that would probably get them on board as well. You know, not to take away from what we're doing here, but if developers and designers even just took the time to say how can we include everybody, that starts, this being at the beginning of a project. That starts a good habit to take and carry on with that. So I always say on Twitter, accessibility is a right not a privilege. That's especially true with color contrast. So then there was an instance where I had a form that I was trying to fill out that was dark blue background. The input was a lighter blue background, and the text was black. I couldn't read that.

JASON: Oof, yeah, that's rough.

TODD: So it's all in thinking about that inclusion and that accessibility aspect. I mean, here's a good example that you have up right now. I have a form, but I have disabled part of that form for a certain reason. That text is going to be like that normal text you have there. As we can see, it fails both contrast checks. So it's just testing out colors, testing out colors with -- and there are a ton of color contrast checkers. If you search for color contrast checker, you're going to get, you know, pages and pages of hits with --

JASON: Do we even get one in the browser? Yeah, check this out. We get a checker in the browser too. We can see what these are. So it'll let you -- use suggested color to fix -- wow! Okay, this is new. That's nice. Now we're at 4.5, right. Then if we want to take it even further, we can get in here and start, like, moving it around. Oh, look at this, y'all. It starts showing you your different ratios. So we can take this up, and we can take this up. Oh, to get it to 7, we have to go all the way -- can't. Can't even get to AAA with this particular background color. And that's a good thing to know, too. That's a choice we just made. This background color cannot meet the most accessible standard.

TODD: Right. And we're in Firefox, correct?

JASON: This one is actually Edge.

TODD: Oh, Edge, okay. That's something I did not know that Edge had.

JASON: I honestly didn't either. I was kind of opening it to see what would happen. (Laughter) But yeah, it's just really, really cool we can do that. And you were saying Firefox does the same thing. So let me open Firefox, and let's go to -- let's poke some fun at Twitter, I think. So, let's see, it opened in the wrong monitor. Let's bring it over here. We'll go in, and let's just do some checking on -- whoa. That opened the whole thing. Let's make that a little bit smaller. I'm going to get one of these. Let's just check. I have a feeling this doesn't meet contrast requirements. So if I want to check that, do I just click here? It does. It exactly meets contrast requirements. Look at it go. That looks really dim to me.

TODD: Terrible.

JASON: Yeah, this kind of challenges my ability to read. It's almost too dark. And you know what, that's a good lesson learned. This technically meets the standard, and I'm still struggling a little bit to read that text.

TODD: Yeah, and if you click on the double chevron there in the dev tools, and you choose accessibility, yep.

JASON: Okay.

TODD: You go to simulate and choose that little drop down.

JASON: Ohh.

TODD: We have the vision simulator for Firefox here.

JASON: Wow. Wow. I mean, that really -- this is -- I mean, look how much the lobster just kind of disappears in different setups. The red is gone. No color. I do like looking at this because when you go to no color, a lot of contrast issues become way more stark. Contrast loss. This is a hard one for me. I feel like this is where I'm headed with my vision right now. Contrast loss like this. You can start to see where things just start to disappear. This little buddy here is real hard to spot with that contrast loss. And I have a feeling with other websites, things would disappear entirely with this simulation.

TODD: Yeah, so somebody in chat said review the KubeCon NA 2021 color scheme.

JASON: KubeCon North America 2021. Oh, wow. There's a lot of color in here. Yeah, let's take a look. Let's see how this one looks. Okay, this looks okay. This is working. Let's see how it looks with no green. That's better. Easier to read.

TODD: Now, there's a WCAG guideline that says, you know, make sure that color isn't the only way to convey a message. That's with, like, form elements and error messaging and stuff like that. But I try and carry that over. If your brand has certain colors, make a palette that kind of responds to what we were looking at in that vision simulator. Some of them may be impossible. Some of them, you know, depending on the brand color. But it can be done. So if -- and I know companies, corporations don't want to take the time to do that. A lot of companies now -- I shouldn't say everybody company, but a lot of companies are looking for accessibility people to join their teams to make things accessible. I think that's probably from a fear of being sued.

JASON: Well, there's like the cold, pragmatic utilitarian sense of, you know, for the business to continue, it needs to avoid litigation and litigation has become so expensive that it's now worth hiring an accessibility professional. But I'm also seeing that there seems to be a shift in the industry, like in just the fabric of the industry where developers care about this. I think a lot of it was lack of awareness. People like you and Marcy Sutton and everybody else doing all this work to raise awareness. It's led to the industry at large having more empathy. So what I've seen is that when we're writing -- like at Netlify, for example, when we write job descriptions, it's not -- like, nobody at our company has ever said we should hire for accessibility because we'll get sued. It's always, you know, let's make sure that's in the job description so people understand that we value it here. And that's very new. Like, you know, I've worked at a lot of companies, even companies that have a classically pretty good record for being accessible, like IBM. Putting accessibility into a drop description wasn't really a thing that you would see, even five, six years ago when I was there. But it is there now. You're seeing it in more job descriptions where it's being baked in. Hey, are you paying attention to accessibility? Let's bring in this person. They're an expert. They can make sure our system meets the needs. I think that's fueled by a combination. There's more empathy in the industry, and there's also more pressure. We saw Domino's get sued. We saw Beyonce get sued. Those sorts of things create -- there's your business case, if you need a business case. But there's a human case that feels like it's actually gaining ground in a way that kind of warms my heart.

TODD: Yeah, and it's really unfair for me to say that it's just a fear of getting sued. That's not totally the case. The reason why I brought up being sued is because we're on a record-breaking track as far as this country in lawsuits. So last year and I think the prior two years -- so since, what, 2018 -- there's been an average of about 2200 lawsuits a year for accessibility alone. This year it was on track for 4500. So it is unfair because that's basically -- you're looking at sites that are being sued in the retail industry and finance industries. Then of course you have the bulk of those in New York and Florida because of the financial aspect in New York and the health care industry in Florida. So that's where that comes in. But that's the chart. So it's 86.4. 86.3 was last year for low contrast.

JASON: And it's pretty heartbreaking this is getting worse, not better.

TODD: Correct. And a lot of what I've run into is the client doesn't have the budget. Well, if you just do it from the beginning, then the client will have it in the budget.

JASON: And to your earlier point, you don't have that budget, what's your legal budget look like?

TODD: Yeah, exactly. Exactly. And the other thing I've heard is, well, we'll get to that after. Again, that carries back to the conversation. If it's done at the beginning, you won't have to go back, and you won't have to redo it.

JASON: You bring up a good point with the let's do it after. This is a conversation that I hear in a lot of places, where you'll hear somebody say something like, you know, oh, well, we want to tackle our technical debt. Somebody says, when are we going to tackle our technical debt? Well, we'll get to that. We just have to get through feature releases. The challenge with that is I've never in my entire career seen or heard of a company that said, okay, we're going to stop feature development and tackle technical debt. So if you don't make accessibility a feature, if you don't make that technical debt part of a feature t will never get released. That's why a lot of times what we see is somebody says I'm going to rebuild the whole app. It's not because they wanted to rebuild the whole app. They're declaring technical debt bankruptcy. They're saying, okay, we're never going to get permission to solve all these problems, so we need to make a business case for rebuilding the whole thing for whatever feature reasons so that we can try to solve these technical debt problems. But then if you don't fix the root problem, which is figuring out how to make technical debt, accessibility, all these things that we claim are critical, if we don't make those part of our feature release process, then we just build that debt snowball again, and two, three years down the road, scratching the whole thing and starting from scratch. Hey, we'll get it right this time. I mean, how much do companies spend rebuilding their entire tech stack that they would have saved if they'd just made these things that make their tech stack unmanageable part of their feature release process?

TODD: That brings up a good point. So if Domino's Pizza had just made their app accessible, that would have cost them $36,000. But instead, they dragged it out and spent millions in court. I mean, right there is a good example. If -- so accessibility is just -- and somebody said it in chat. Accessibility is good design. It's true. It's very true. Accessibility is good workflow. Accessibility is -- and you know, you brought up accessibility being a feature. Accessibility isn't really a feature as much as a methodology to improve that feature.

JASON: Yes.

TODD: Or to improve that component. Accessibility isn't just a checklist either. I mean, you have -- it's not just a checklist. It's not just WCAG guidelines either. There's so much gray area right now in the WCAG guidelines, and if anybody in the chat has gone through and tried to read the WCAG guidelines, it is a very technical manual, which is what we're working on in WCAG 3. It uses plain language. I've been railing for a while now, we have to make the guidelines readable for people that are just starting out, just wanting to know how to implement accessibility. Right now if you look at 2.2, it's a very technical manual. So a lot of very bright people are working on the plain language for someone that says how do I get started.

JASON: Yeah, I think --

TODD: There are many ways.

JASON: And somebody brought up a good point. Unfortunately, dev tools won't help you with redesigning the brand.

TODD: Correct.

JASON: That's a good point. One of the big challenges we run into is that a lot of times developers don't have control over things like colors. That points to, I think, the need for design and dev to have not just hand-off points. Like, here's the design. Developers, I know, hate meetings. So a lot of times devs will do whatever they can to not have to go to meetings, or they'll put a meeting on in the background and check their Twitter, but a lot of times those design meetings, those product meetings, that's where we get to influence these kinds of things. If we can think about the product implications, we can have conversations around the lines of, okay, well, if we do this wrong, here's how this is going to make dev harder, and here's how we're going to waste a lot of money. That can be a -- like, being in those meetings is frustrating. I'm saying this as somebody who has basically ascended to the level of my career where my entire job now is meetings. But if you can figure out how to identify where those meetings are happening and show up and be helpful, you know, if you show up and say that's a bad idea, that's not going to work well. But you can go in collaboratively and say, hey, you want to make a great design, let's make sure it's great for everybody. Here are some considerations when we're building for the web to make sure that we don't have rework, that we don't open ourselves up to litigation, that we make sure that our users aren't angrily tweeting about us because we didn't include them in our new design. We can provide that guidance early in the process as part of that discussion. That can lead to much better designs, much better product prioritization because at the end of the day, not everybody's an expert in everything. Product managers have maybe never had to think about accessibility, so they're not even aware that you need time to do that sort of work. If we don't tell them until they give us the scope, how -- like, we can't expect them to rewrite the plan. So we need to be there when the plan is happening and share. That's one of the big challenges for developers. So much of this job is social. So much of this job is interpersonal. Being a developer is 40% writing code and 60% making sure that the things we're told to do are the right things. That requires, unfortunately, talking to people. (Laughter)

TODD: Yes, yes, it does. It does. And I wrote an article, which is on Smashing Magazine, about having somebody on each team as an accessibility advocate --

JASON: Is this the right one?

TODD: Yes, it is. You know, having somebody that is an accessibility advocate or champion in design and in development and in marketing and in QA. Having those people meet and having them have a positive, diplomatic discussion about how do we make this product or our products accessible for everyone and take the load of, again, stress, time, money, off developers, designers, QA, marketing, the whole company as a whole, really.

JASON: Yeah. And I see Climate Designer in the chat just mentioned they're focused on sustainability, but what we're talking about with accessibility, like, at the end of the day it's advocacy. Are you making sure that the things that you care about have a voice at the table at the right points in the conversations. Usually, you'll find that if you make an issue visible, other people will say, oh, of course. It's not like people are going, yeah, never be accessible. You know, screw accessibility. It's more that it just never enters their consciousness. If you can elevate that conversation around accessibility, around sustainability, around anything that's important, around inclusion, diversity, equity, all those things we care about, if we make sure that enters the planning phase of discussion, which again you got to get into the right rooms, got to have discussions, got to be willing to walk somebody around to the point. We don't just get to say do it or else. Those things, you know, usually what I've found is when you bring it into the planning phase, people go, oh, yeah, you're right, we should be thinking about that. How do we make that work? Then you might end up with a compromise that you're not 100% happy with, but you know, another word for compromise is halfway happy. And halfway happy is better than we'll get to that later. You want to get as many wins as you can. Sometimes you get all the way there. Like with accessibility at Netlify, we were very lucky. Our front-end team showed up to the meetings, they've been talking to the designers. The designers are aware of and care about accessibility, and they've collaborated so that the design system that we're building is ground-up built with accessibility in mind. You know, all the labels, all the screen reader implementations, color contrast, all those things actually get tested at implementation point. Here's a design. Does this pass accessibility? Okay, now we can send it to development. Then the same thing. Does this dev actually pass accessibility? Great, now it can move into the product. Those are gates that happen because of the way that we talk in our company about the way decisions get made. So this isn't a thing that happens by accident. And it's not a thing that happens because we have one hero in the company who cares about accessibility. This is because it's now part of our cultural fabric because those conversations happen.

TODD: Yeah, and once you get teams buying into that, once -- and my first point in getting an organization on accessibility is if you get that stakeholder or those stakeholders into and buying into accessibility, it's going to trickle down to everybody else, which makes it a lot easier to get that culture in that organization.

JASON: Absolutely.

TODD: And you were talking about Netlify. That's a great culture to have because I bet everybody isn't frazzled trying to go back and say, oh, we have to make this, you know, accessible because it's not, for whatever reason, and people are scrambling around to do changes and things like that. So yeah, that's a great culture.

JASON: I mean, we scramble for other things, but we're very -- you know, every company's got its rough edges. I feel like one of the ones I'm happy isn't a pain point for us is thinking about this sort of thing. It just comes up as part of a consideration. Even in product, when we see the product managers writing down what's going to happen, it shows up as a checklist. It's like, did we check for this? Are we paying attention to this? That, to me, is really, really indicative of the fact that we had these conversations and that people are standing up, they're showing up in meetings, they're weighing in. That drives change. Does it feel like it moves way too slow and requires more meetings than it should? Sure. It's a big company. That's how bureaucracy works. But did it actually make an impact? 100%, yes.

TODD: Yeah, and I actually wanted to touch upon -- so, I had a friend of mine send me some slides about the economic part of -- and let's use color contrast, for instance. Individuals with visual disabilities account for $10.3 billion worth of e-commerce revenue, just in this country alone.

JASON: Dang.

TODD: So it's crucial and important for a brand or company to say we need to have a culture of accessibility and inclusion and inclusive design because you want that company to make money in order to pay its people, in order to sell the product. That just makes sense. I mean, you have companies with inaccessible product or presence on the web, and they're not selling anything going, why are we not selling anything? Well, your stuff is not accessible.

JASON: And it's one of those things that also comes in. It's the incremental gains. If you have something that is 50% good and you start getting into the millions and billions in revenue, there's that famous study about web performance, for example. The faster somebody can load your thing, the more likely they are to use it. They found for every like 100 milliseconds they were able to shave off a page load time, it had a legitimate hundreds of thousands or millions of dollars in impact on their revenue. Like, 100 milliseconds is less time than it takes us to blink. And that is -- like, to think that tiny little bit makes that level of impact, a six-figure-plus impact on your business, that is a huge sign that incremental gains add up. And when you're trying to build a business -- and at the end of the day, I know we'd all love it if businesses could be, you know -- well, businesses aren't about making money, but the fact of the matter is everything costs money. If your business doesn't make money, nobody gets paychecks, you can't afford the resources, it all shuts down. You got to work somewhere else. So if we want the business to be the best business it can be, we have to factor revenue into that. We have to be thinking about how do we make the company revenue in a way that's good. So if we can incrementally increase revenue by increasing accessibility as opposed to incrementally increasing revenue by selling user data, for example, I choose accessibility. Like, I'd rather -- I would much rather make the extra money by doing the work to make this site accessible and accessing that market that wants to pay money, that wants to be included in the internet, much rather than I'd want to sell anybody's data or get into the dark patterns of how to get people to -- oh, I don't want to build on exit popovers. I don't want to build unsubscribe patterns. I hate that stuff. I don't want to do that work. That's not fun.

TODD: Or spend X amount of dollars for a contract and saying, oh, we'll just use an accessibility overlay. I have to go back to that.

JASON: Oh, yeah. Talk about accessibility overlays. This is not even something I'm familiar with.

TODD: So there are companies out there that will remain nameless because of legal reasons. If you look it up online, you can find that, who they are. Basically, it's injecting JavaScript into your site or putting it in the code. I've heard it's one or two lines of code, and it brings up an overlay. Let's bring up Heatonist. I'll put that in the chat for Zoom. Heatonist.com. So you'll see on the left-hand side, that's an accessibility overlay. That's another problem right there. These tools here we're looking at do not make a website accessible. They exacerbate the problem for screen reader users, for blind users, for visually impaired users, even though there are, as you can see, several -- you just can't switch it on and off. That's basically it. They just don't work. An accessibility overlay, I like to say, makes your site about as accessible as me putting on a pair of Nikes and playing basketball as good as Michael Jordan. It's just not possible. It'll never happen. It makes these companies money, but it doesn't make things accessible. And they actually block out tools that I use in the -- for extensions and in the dev tools. It blocks those tools from doing an accessible audit. So I guess this is the modern day snake oil, bottom line.

JASON: So it's sort of a -- I mean, I'm sure it's done with good intentions, but it's sort of exacerbating the problem, rather than solving it.

TODD: Yes.

JASON: I've never seen one of these before. So this just tries to -- oh, god. What is it doing? And you can only turn on one at a time?

TODD: Uh, yeah.

JASON: Oh, is that supposed to help?

TODD: I don't think so.

JASON: Oof, oof. Oh, started beeping. And I broke it. Okay. Yeah, I see what you mean. Just trying to click that a little bit, it doesn't feel like it's -- I mean, I'm coming at this with a very specific experience of the web, where I do things a certain way. If I need any of these features, even just finding this is kind of a challenge.

TODD: Right, because you have that pop-up to sign up for their newsletter at the beginning. Then you have the chat bubble on the lower right. So you're getting cognitive overload from the very beginning when you go on this site. Yes, that is the brand from "First We Feast." I informed them about a month ago, you have an overlay, it doesn't make your site accessible. People in the accessibility space, we're willing to email a company and say, hey, you know, this isn't helping, it's hurting. Could you reconsider? Some companies do. Apparently, they haven't reconsidered. They've said, and I find this a lot, as well as many other people in the accessibility space do, we get a lot of we'll let our dev team know about it. Thanks for letting us know. And that's it.

JASON: And that goes back to what we were talking about with the tech debt snowball. I'm sure that somebody on the dev team got that ticket and was like, see, I told you we need to fix this. Product was like, sure, we'll get to that later. We got to get through this feature launch, though. Again, nobody is being evil. Just priorities are weird and you're not bundling things together. It just comes down to this idea of, like, you're never going to get six months to fix all the things that are wrong with your product. No one is ever going to take their foot off the gas with features and, oh, we got a launch coming up, we got this marketing campaign we got to get ready for, we got this feature we need to release. That never works. Again, companies have to make money, or they cease to exist. In any sufficiently good or successful company, it's going to have competition. So if you take your foot off the gas, somebody just comes in and does all the things you were planning on doing, but they do it faster. Then you lose your audience. Again, now you have to go work for a new company. So how do we, instead of saying we need to, like, focus on this as a primary thing, how do we build it into the process so that it doesn't need focus at all? It just happens as part of the way we do business. And I think that's -- like, again, you have to build it into the fabric through those conversations and through the way that you make sure that the right people are in the right meetings to make sure this stuff gets advocated for.

TODD: Yeah, yep. That's exactly it. And somebody else in the chat said those overlays try to trick Wave, which is from WebAIM. It's a tool for auditing, to pass the audit. That's true. And that's one of the tools that that particular overlay blocks. There's a Chrome extension which actually blocks that overlay from appearing, if you go on a site that has that overlay.

JASON: Oh, interesting.

TODD: I can't remember what the name of that is. But it's a very handy tool, and I think I may have it. Let's see. AccessiByeBye, yeah.

JASON: So if you want to not see those, you can drop this in and use it. Yeah, I mean, it's funny because, you know, I didn't expect this conversation to go this way. I'll be completely honest. I'm glad that we're talking about it because it points out, I think, something that is really at the core of a lot of the trouble that we have as developers. I think some of it is that as developers, we sometimes have a tendency to take a backseat on planning and to say, you know, well, I wouldn't have done it that way. We're in trouble because this plan is bad. The leadership team or the product team or the designers, you know, they made bad decisions and dropped them on us. You can, as a developer, just sit at the end of the chain and take whatever falls down the waterfall, but when we talk about things like agile, when people talk about collaborative, iterative processes and shipping as a team, not as phases, those sorts of things, they're not there as, like, productivity hacks. That's what they've become. They've kind of been memed that way, into, okay, we're going to do agile. You're going to do backlog rooming. You're going to do T-shirt sizing of story points. That stuff is where the productivity hacking comes in, but at the core of what's being proposed here is developers need to be included earlier in the process, and that means that we have to take some agency over what happens in our jobs. That means shoulder your way into that planning meeting. Sit through the frustrating calls where everybody bike sheds over whether or not we should build this project as all. If you can get in that room and if you can advocate for the things that are important, you can get it built into the plan. But it's very, very hard after something has gone through six months of planning to change the plan. Everybody just goes, no, we'll put it in the next plan. So you have to be there during the planning phase. You have to have that frustrating bureaucratic, multi-month discussion about what's going to be built and why so that you can make sure the things that matter get built into the fabric of your company, into the plan itself, and not become side cars that can't make it in because everybody starts cutting corners when things get busy. Right?

TODD: Yes.

JASON: So yeah, this ended up being a pretty philosophical episode, Todd. I'm not going to lie. (Laughter)

TODD: I've never been accused of being philosophical. So it's new territory for me. But yeah, it's tough kind of wedging that accessibility part when something is, like you said, after the planning stages or six months into the planning stage, or even after something has been pushed out and an aspect of that project was overlooked. Just like color contrast. Color contrast, that's an easy fix. I mean, you just go into the CSS service and change a hex value or whatever and make sure it covers a ratio and you're done. Other things, like keyboard accessibility, you know, whether someone can use -- I want to make sure that I say accessibility is more than just, you know, somebody who's Deaf, somebody who's blind, somebody who has -- so, let me say it this way. Somebody that uses a joystick to traverse the site, somebody that uses a sip-and-puff machine, somebody that uses a braille machine because not all blind people use a screen reader. There are many facets to accessibility and some that I haven't even known up until this year, which blew my mind. That's part of me being in the W3C on the accessibility in the groups and seeing these things. It's very enlightening to see some of this stuff that I've never seen before. So that carries over to my advocacy.

JASON: And again, every single thing that you just listed, if we write semantic HTML and we make sure that our JavaScript isn't hijacking default functionality, we're already the vast majority of the way there.

TODD: Yes.

JASON: And so a lot of this can actually be solved by doing less. And by being intentionally minimal in what we implement in our front ends. That actually means we're going to be able to ship faster. It means we have less to maintain. It means things will be more agile and iterable. There are so many benefit, and you could almost argue that accessibility -- I'm not actually saying this, so please don't quote this out of context. You could go in and even say, accessibility is not the reason we're doing this. There are so many outside benefits that happen when you make these choices that even if you weren't thinking about accessibility, it's still worth doing. Now, at the bottom of everything, our core motivation to do anything on the internet should be I want to make this more accessible to more people. Like the founding philosophy of the internet is information wants to be free. If it's not for everybody, it's not free yet.

TODD: So you bring up something that just triggered this thought. You know how we go on to -- we're looking at news items, for instance. We get to a newspaper online, and they have a pay wall. You notice that all the good stuff that we want to read is behind a pay wall, but all the bad stuff is freely available. That's accessibility right there. I want accessibility for the good stuff to read, not the bad stuff. But the bad stuff behind a pay wall, then I'll never look at it, and I don't think anybody else would either.

JASON: Yeah, that starts putting us into a really far down the philosophical rabbit hole here. But you raise a good point. When people are doing -- and how do we solve that problem? We don't like ads. We don't like pay walls. For somebody to do that kind of work, to write those in-depth, researched articles, it costs money. Somebody has to pay for it. Is it a public good if it becomes a nationally owned utility where somebody can get paid to do good journalism? Is it still going to be good journalism? We don't know. My gut says probably not, so we got to pay for it some other way, right? That really, really makes it hard. You know, the other folks, they make their money in other ways, right. When you're peddling misinformation, you're not doing it because you want to get paid for journalism. You're doing it because that misinformation drives a different profit motive. And that really, really makes the internet hard for doing the right thing sometimes.

TODD: You want to get back to color contrast?

JASON: We probably should. (Laughter)

TODD: If not, I'll go off on a tangent on lobster rolls.

JASON: So let's maybe bring this home a little bit. For somebody who wants to start building just a piece of this out, we want to make our websites more accessible. The way we're going to do that is moving forward, everybody watching this stream right now is going to do an accessibility check. What do we want to do with our color contrast to make sure that it passes that accessibility check for us?

TODD: Go a little above the minimum requirements. So if we look at the WCAG guidelines, and if you go to the quick ref, which is that first link right there in the content area, if you go to 1.4.3, which is contrast minimum, this is a great bookmark for people I recommend. The visual presentation of text and images of text has a contrast ratio of at least 4.5:1, except for the following, which goes into what we discussed earlier, the large text and so on and so forth. Go a little above that 4.5:1. Go 5:1, 6:1, maybe even 7:1. You might hit AAA. That's fine. A lot of people don't go for AAA unless it's specifically required by a client or by an organization. They want to reach AAA level. So basically for the most part, you're going to find people will settle for the passing AA requirement. Go a little above and beyond that. So that ratio you have right there, 6.4, do that. But make sure -- so if we go to another site, it's called whocanuse.com, this will give us, if we scroll down, how people see that simulation with protanopia, so on, and so forth.

JASON: Oh.

TODD: You get a great representation of the percentage of the people that have this. Cataracts, 33%. This is a great site to test with as well. And if you go back to the bottom, I do want to touch upon this briefly. I love this part. Situational vision events. You're trying to look at your phone with the sun beaming down on it and you can't see it. That is an accessibility issue. And you want to -- I know a lot of people are like, well, you can just cover up the part with your hand, but some people can't. You want that contrast there to address that situation.

JASON: And you're bringing up some really good -- so let's go here to something that is -- let's see. Let's go to the 4.5. Okay. So we'll get right to the 4.5. This is technically accessible. This passes accessibility, but let's go look at what happens in all these different situations. It's mostly okay. This one gets a little tricky. This is pretty rough here. And yeah, we can see here it starts getting bad in a few of these where the contrast just isn't there.

TODD: So to answer your question, go above and beyond that. Try to hit that AAA mark. If you can't, keep working with the brand, or if you're working with a company that makes it difficult because they already have an established color palette for their organization, that's when you're going to get trouble. As I look into the chat, I do have a list of accessibility dev tools that we can go through real quick if we have time.

JASON: Yeah, we got a few minutes.

TODD: There's another. Do they have a situational event like when I've been staring at my screen all day and can't focus anymore? Yes, I call that going outside and going for a walk.

JASON: (Laughter)

TODD: That's the best dev tool I have for that because I do that all the time. Yesterday was a 12-hour day for me. So I got up a few times and went for a walk. So, some good tools. Just real quick. We got the Wave tool. It's an extension for Chrome, Edge, and Firefox. That's from WebAIM. That's the first tool I will use. That ties into the title of this stream today. That's the first thing I check during an audit. Is the color contrast going to fail in some places? Is it going to pass? Looking at different components, different headings, text. Headings are very important. And Jason, you have captioning for this. Captioning is very important to have a color contrast because you will see sometimes on a YouTube video, it's just white text over the background. You have that white text on that black background, which is terrific.

JASON: I should probably look at this now, though. I think this might be pure white on pure black. So I should probably go fix it up so it doesn't cause the halos for folks.

TODD: Right, right. But that contrast, you know, tone it down a little bit, get that all worked out. That's perfect for captioning. You know, if you have, for instance, Keynote slides that use a background, I had one in my talk for Web Directions, which is coming up on November 5th. I have a picture of a lobster roll with text over it. You can't see that captioning because of the busy background. But if you have that black background or that darker background on that white or lighter white text, you're going to be able to see those captions. So captioning is important as well.

JASON: You bring up something -- sorry, I keep cutting you off. You bring up something that I think -- I don't know if this was intentional. But meme culture on the internet actually nailed the accessibility of this because they do the white text with a thick black outline so no matter what you put this on, you can put any color image on here. So if we go to Unsplash and we look for something bright, mine was pretty dark. But if I take this image and bring it in here and let's drop one in. Then I take this text and bring it over and bring it to the front, even on this really, really light background, it's still legible. I don't know if this was just because somebody one day was like, man, I can't read my meme, but it is pretty powerful that you get -- like, you know, the way we've done this. I'm sure it's not perfect, but it mostly solves this problem in a way that if I turn this border off, that is awful. I see stuff like this all the time where somebody will put text like this and you just lose some of it. If you move it here, okay, that's probably fine. If you move it up here, it's atrocious. Down here, it's pretty bad. But if you put this stroke back on, no matter where we put it, you can now read it on this photo. I think that's pretty cool. So plus one to the cheeseburger crew for getting that one right.

TODD: Yeah, yeah. So Wave is a great tool to start off with. I start, like I said, my audits using Wave. It also gives you errors and issues. Error, something does not work. I don't know if they have an example. I think they might have an example if you scroll down on that page. You can see where the errors are, where things fail WCAG guidelines, issues where it's just giving you a warning. It also gives you contrast checker, which is included in that as well. Very important to look at. It shows you the heading structure of a web page because skipping a heading level, that's a failure as well because that has an impact on screenreaders and keyboard users as well, as far as skipping a heading level. So Wave is a good tool. The axe DevTools is a good one. I usually do that at the end of my audit. That gives you a more technical rundown of errors, warnings. It gives you a good explanation of here's what's wrong with this. Here's how to fix it. Here's where it is on the screen and in your code. And Wave kind of does that as well. Another tool is from TPGI. That's the -- oh, good grief, I'm blanking on that one.

JASON: Oh, I did it wrong. TPGI.

TODD: That is, I believe, the ARC Platform.

JASON: I'm looking at something called ARC Platform on TPGI here.

TODD: I think that might be it. You know what, I should know this stuff before I even start blabbing.

JASON: It's all right because we've got some really strong stuff here. We've got the DevTools in Edge and Firefox for sure, contrast checkers. I think that's rolled out to all modern browsers at this point, which is good. Firefox has those simulation tools for checking on your -- you go to the accessibility tab, and you can simulate the different styles to see how everything looks. This is pretty powerful stuff here.

TODD: Yep. If you go to the check for issues, you can also check for color contrast. Yep, right there. You can check contrast there.

JASON: Oh, look at it go. Oh, wow. This whole website has issues. Okay. I see why this one was suggested.

TODD: Chrome has a built-in tool. If you go into the code and hover over a certain part, it will give you a kind of tool tip with the color contrast as well.

JASON: Oh, nice.

TODD: In Chrome, if you look in the dev tools. You can also use, if you go into the spare mental part of the Chrome dev tools and turn it on, you can use the new scoring. It's APCA scoring.

JASON: APCA.

TODD: Yep. And that will give you an overview of what contrast will be like in the new scoring system. I don't really recommend using it right now. It's still being worked on, of course. But it's a terrific look at if you want to experiment what things will be like for color contrast down the road.

JASON: Great.

TODD: That tool I've blanked on is the ARC Toolkit for TPGI.

JASON: ARC Toolkit. And with that, I unfortunately need to cut you off because we are out of time. So make sure you go and follow Todd on Twitter. Fire these questions off. Get in there. Follow Todd and ask your accessibility questions. I'm sure that there's probably a little list coming up. But yeah, thank you so much for hanging out today. We are looking at an absolute blast of a week. This is stream number seven of eight. We've got one more tomorrow. But first and foremost, let's give a quick shout out to our captioning. We've had Rachel here with us all day today from White Coat Captioning making this show more accessible. That's made possible through the support of our sponsors, Netlify, Fauna, and Auth0. So thank you all so much for doing that. Make sure that while you're checking out the site, you check out the schedule because we have some really incredible stuff going on here where you can hit this add on Google Calendar. That'll add it to your calendar. Tomorrow we'll have Aisha Blake, who is absolutely wonderful, if you've never seen her before. Make sure you come and join. We saw New Relic raided earlier. Thank you for that. She's going to be showing us how to add observability. If you're not familiar with observability, you should show up and watch this because it is extremely, extremely useful. Then next week, we've got distributed databases on the Jamstack. We're going to be doing a whole bunch of stuff. It just keeps going. I've got a bunch in my inbox that I haven't even added yet. So it's going to be great. Make sure you go here. Follow on Twitch if you want to subscribe, or you can also always find me on YouTube as well if you want to watch these later. Todd, any parting words for everyone before we wrap this one up?

TODD: Yeah, accessibility is a right, not a privilege. Please make things accessible. If you have any questions, please reach out to me on Twitter. I'll be more than happy to answer them. And if I don't know the answer, I can always find the answer for you. And yeah, just eat more lobster too.

JASON: (Laughter) Love it. All right. Thank you so much, Todd. And thank you, chat. We're going to find somebody to raid. Hang out. We'll see you all tomorrow.