01:09 - Todd’s Superpower: Advocacy For Accessibility

• Getting Started
  • Designing With Web Standards by Jeffrey Zeldman
  • The A11Y Project
  • W3C

06:18 - Joining The W3C

• The W3C Community Page

07:44 - Getting People/Companies/Stakeholders to Care/Prioritize About Accessibility

• Making A Strong Case For Accessibility by Todd Libby
• Diplomatic Advocacy
• You Don’t Want To Get Sued! / $$$
• “We are all temporarily abled.”

15:20 - The Domino's Pizza Story

• Supreme Court hands victory to blind man who sued Domino’s over site accessibility

18:21 - Things That Typically Aren’t Accessible And Should Be

• The WebAIM Million Report
• WCAG
  • Color Contrast
  • Missing Alt Text on Images
  • Form Input Labels
    • What’s New in WCAG 2.1: Label in Name by Todd Libby
  • Empty Links
  • Not Using Document Language
  • Triggering GIFS / Flashing Content
  • Empty Buttons – Use a Button Element!!
  • Tab Order
  • Semantic HTML, Heading Structure

26:27 - Accessibility for Mobile Devices

• Target Size
  • Looking at WCAG 2.5.5 for Better Target Sizes
• Dragging Movements

28:08 - Color Contrast

• Contrast Ratio

33:02 - Designing w/ Accessibility in Mind From the Very Beginning

• Accessibility Advocates on Every Team
• Accessibility Training

36:22 - Contrast (Cont’d)

38:11 - Automating Accessibility!

• axe-core-gems

Reflections:

Mae: Eyeballing for contrast.

John: We are all only temporarily abled and getting the ball rolling on building accessibility in from the beginning of projects going forward and fixing older codebases.

Mandy: Using alt-tags going forward on all social media posts.

Todd: Accessibility work will never end. Accessibility is a right not a privilege.

This episode was brought to you by @therubyrep of DevReps, LLC. To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode

To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps. You will also get an invitation to our Slack community this way as well.

Transcript:

JOHN: Welcome to Greater Than Code, Episode 251. I’m John Sawers and I’m here with Mae Beale.

MAE: Hi, there! And also, Mandy Moore.

MANDY: Hi, everyone! I'm Mandy Moore and I'm here today with our guest, Todd Libby.

Todd Libby is a professional web developer, designer, and accessibility advocate for 22 years under many different technologies starting with HTML/CSS, Perl, and PHP. Todd has been an avid learner of web technologies for over 40 years starting with many flavors of BASIC all the way to React/Vue. Currently an Accessibility Analyst at Knowbility, Todd is also a member of the W3C. When not coding, you’ll usually find Todd tweeting about lobster rolls and accessibility.

So before I ask you what your superpower is, I'm going to make a bet and my bet is that I'm 80% positive that your superpower has something to do with lobster rolls. Am I right?

[laughter]

Am I right?

TODD: Well, 80% of the time, you'd be right. I just recently moved to Phoenix, Arizona. So I was actually going to say advocacy for accessibility, but yes, lobster rolls and the consumption of lobster rolls are a big part.

MAE: I love it. That's fantastic.

MANDY: Okay. Well, tell me about the advocacy. [chuckles]

TODD: So it started with seeing family members who are disabled, friends who are disabled, or have family members themselves who are disabled, and the struggles they have with trying to access websites, or web apps on the web and the frustration, the look of like they're about ready to give up. That's when I knew that I would try to not only make my stuff that I made accessible, but to advocate for people in accessibility.

MAE: Thank you so much for your work. It is critical. I have personally worked with a number of different populations and started at a camp for children with critical illnesses and currently work at an organization that offers financial services for people with disabilities – well, complex financial needs, which the three target populations that we work with are people with disabilities, people with dementia, and people in recovery. So really excited to talk with you today. Thanks.

TODD: You’re welcome.

JOHN: When you started that journey, did you already have familiarity with accessibility, or was it all just like, “Oh, I get to learn all this stuff so I can start making it better”?

TODD: So I fell into it because if you're like me and you started with making table-based layouts way back in the day, because what we had—Mosaic browser, Netscape Navigator, and Internet Explorer—we were making table-based layouts, which were completely inaccessible, but I didn't know that.

As the web progressed, I progressed and then I bought a little orange book by Jeffrey Zeldman, Designing with Web Standards, and that pretty much started me on my journey—semantic HTML, progressive enhancement in web standards, and accessibility as well. I tend to stumble into a lot of stuff [laughs] so, and that's a habit of mine. [laughs]

MAE: It sounds like it's a good habit and you're using it to help all the other people. So I hate to encourage you to keep stumbling, but by all means.

[laughter]

Love it.

If you were to advise someone wanting to know more about accessibility, would you suggest they start with that same book too, or what would you suggest to someone stumbling around in the dark and not hitting anything yet?

TODD: The book is a little outdated. I think the last edition of his book was, I want to say 2018, maybe even further back than that. I would suggest people go on websites like The A11Y project, the a11yproject.com. They have a comprehensive list of resources, links to learning there.

Twitter is a good place to learn, to follow people in the accessibility space.

The other thing that, if people really want to dive in, is to join The W3C. That's a great place and there's a lot of different groups. You have the CSS Working Group, you have the accessibility side of things, which I'm a part of, the Silver Community Group, which is we're working on the Web Content Accessibility Guidelines 3.0, which is still a little ways down the road, but a lot of great people and a lot of different companies. Some of those companies we've heard of—Google, Apple, companies like that all the way down to individuals. Individuals can join as individuals if your company isn't a member of the W3C.

So those are the three things that I mainly point to people. If you don't really want to dive into the W3C side of things, there's a lot of resources on the a11yproject.com website that you can look up.

MANDY: So what does being a member entail? What do you have to do? Do you have to pay dues? Do you have to do certain projects, maybe start as an individual level, because I'm sure we have mostly individuals listening to the show. Me as a newbie coder, what would I do to get started as a member of this initiative?

TODD: Well, I started out as an individual myself, so I joined and I can get you the link to The W3C Community Page. Go to sign up as an individual and someone will approve the form process that you go through—it's nothing too big, it's nothing complicated—and then that will start you on your way. You can join a sub group, you can join a group, a working group, and it doesn't cost an individual. Companies do pay dues to the W3C and if your company is in the W3C, you get ahold of your company's liaison and there's a process they go through to add you to a certain group.

Because with me, it was adding me to The Silver Community Group. But as an individual, you can join in, you can hop right into a meeting from there, and then that's basically it. That's how you start.

JOHN: What are the challenges you see in getting not only the goals of a W3C, but I'm assuming specifically around accessibility?

TODD: Some of the things that I've seen is buy-in from stakeholders is probably the number one hurdle, or barrier. Companies, stakeholders, and board members, they don't think of, or in some cases, they don't care about accessibility until a company is getting sued and that's a shame.

That's one of the things that I wrote about; I have an article on Smashing Magazine. Making A Strong Case for Accessibility, it's called and that is one of few things that I've come across. Getting buy-in from stakeholders and getting buy-in from colleagues as well because you have people that they don’t think about accessibility, they think about a number of different things. Mostly what I've come across is they don't think about accessibility because there's no budget, or they don't have the time, or the company doesn't have the time. It's not approved by the company.

The other thing that is right up there is it's a process—accessibility—making things accessible and most people think that it's a big this huge mountain to climb. If you incorporate accessibility from the beginning of your project, it's so much easier. You don't have to go back and you don't have to climb that mountain because you've waited until the very end. “Oh, we have time now so we'll do the accessibility stuff,” that makes it more hard.

MAE: John, your question actually was similar to something I was thinking about with how you developed this superpower and I was going to ask and still will now. [chuckles] How did you afford all the time in the different places where you were overtime to be able to get this focus? And so, how did you make the case along the way and what things did you learn in that persuasion class of life [chuckles] that was able to allow you to have that be where you could focus and spend more time on and have the places where you work prioritize successful?

TODD: It was a lot of, I call it diplomatic advocacy. So for instance, the best example I have is I had been hired to make a website, a public facing website, and a SAAS application accessible. The stakeholder I was directly reporting to, we were sitting down in a meeting one day and I said, “Well, I want to make sure that accessibility is the number one priority on these projects,” and he shot back with, “Well, we don't have the disabled users,” and that nearly knocked me back to my chair. [laughs] So that was a surprise.

MAE: There's some groaning inside and I had to [chuckles] do it out loud for a moment. Ooh.

TODD: Yeah, I did my internal groaning at the meeting so that just was – [chuckles] Yeah, and I remember that day very vividly and I probably will for the rest of my life that I looked at him and I had to stop and think, and I said, “Well, you never know, there's always a chance that you're able, now you could be disabled at any time.” I also pointed out that his eyeglasses that he wore are an assistive technology. So there was some light shed on that and that propelled me even further into advocacy and the accessibility side of things.

That meeting really opened my eyes to not everyone is going to get it, not everyone is going to be on board, not everyone is going to think about disabled users; they really aren't. So from there I used that example. I also use what I call the Domino's Pizza card lately because “Oh, you don't want to get sued.’ That's my last resort as far as advocacy goes. Other than that, it's showing a videotape of people using their product that are disabled and they can't use it. That's a huge difference maker, when a stakeholder sees that somebody can’t use their product.

There's numbers out there now that disabled users in this country alone, the United States, make up 25% of the population, I believe. They have a disposable income of $8 trillion. The visually disabled population alone is, I believe it was $1.6 billion, I think. I would have to check that number again, but it's a big number. So the money side of things really gets through to a stakeholder faster than “Well, your eyeglasses are a assistive technology.”

So once they hear the financial side of things, their ears perk up real quick and then they maybe get on board. I've never had other than one stakeholder just saying, “No, we're just going to skip that,” and then that company ended up getting sued. So that says a lot, to me anyways. But that's how I really get into it.

And then there was a time where I was working for another company. I was doing consulting for them and I was doing frontend mostly. So it was accessibility, but also at the same time, it was more the code side of things. That was in 2018. 2019, I went to a conference in Burlington, Vermont. I saw a friend of mine speaking and he was very passionate about it and that talk, and there was a couple others there as well, it lit that fire under me again, and I jumped right back in and ever since then, it's just then accessibility.

MAE: You reminded me one of the arguments, or what did you say? Diplomatic advocacy statements that I have used is that we are all temporarily abled. [chuckles] Like, that's just how it is and seeing things that way we can really shift how you orient to the idea of as other and reduce the othering. But I was also wondering how long it would be before Pizza Hut came up in our combo.

[laughter]

MANDY: Yeah, I haven't heard of that. Can you tell us what that is?

TODD: [chuckles] So it was Domino’s and they had a blind user that tried to use their app. He couldn't use their app; their app wasn't accessible. He tried to use the website; the website wasn't accessible. I have a link that I can send over to the whole story because I'm probably getting bits and pieces wrong. But from what I can recall, basically, this user sued Domino's and instead of Domino's spending, I believe it was $36,000 to fix their website and their app, they decided to drag it out for a number of years through court and of course, spent more money than just $36,000.

In the end, they lost. I think they tried to appeal to the Supreme Court because they've gone up as high as federal court, but regardless, they lost. They had to – and I don't know if they still have an inaccessible site, or not, or the app for that matter because I don't go to Domino’s.

But that's basically the story that they had; a user who tried to access the app and the website, couldn’t use it, and they got taken to court. Now Domino's claimed, in the court case, that he could have used the telephone, but he had tried to use the telephone twice and was on hold for 45 minutes. So [laughs] that says a lot.

JOHN: Looks like it actually did go to the Supreme Court.

TODD: Yeah. Correct me if I'm wrong, I think they did not want to hear it. They just said, “No, we're not going to hear the case.” Yeah, and just think about all these apps we use and all the people that can't access those apps, or the websites. I went to some company websites because I was doing some research, big companies, and a lot of them are inaccessible. A little number that I can throw out there: every year, there's been a little over 2,500 lawsuits in the US. This year, if the rate keeps on going that it has, we're on course for over 4,000 lawsuits in the US alone for inaccessible websites. You've had companies like Target, Bank of America, Winn-Dixie, those kinds of companies have been sued by people because of inaccessible sites.

MAE: Okay, but may I say this one thing, which is, I just want to extend my apologies to Pizza Hut.

[laughter]

MANDY: What kinds of things do you see as not being accessible that should be or easily could be that companies just simply aren't doing?

TODD: The big one, still and if you go to webaim.org/projects/million, it's The WebAIM Million report. It's an annual accessibility analysis of the top 1 million home pages on the internet.

The number one thing again, this year is color contracts. There are guidelines in place. WCAG, which is the Web Content Accessibility Guidelines, that text should be a 4.5:1 ratio that reaches the minimum contrast for texts. It’s a lot of texts out there that doesn't even reach that. So it's color contrast.

You'll find a lot of, if you look at—I’m looking at the chart right now—missing alt texts on images. If you have an image that is informative, or you have an image that is conveying something to a user, it has to have alternative text describing what's in the picture. You don't have to go into a long story about what's in the picture and describe it thoroughly; you can just give a quick overview as to what the picture is trying to convey, what is in the picture.

And then another one being another failure type a is form input labels; labels that are not labeled correctly. I wrote a article about that [chuckles] on CSS-Tricks and that is, there's programmatic and there’s accessible names for form labels that not only help the accessibility side of it, as far as making the site accessible, but also it helps screen reader users read forms and navigate through forms, keyboard users also.

Then you have empty links and then a big one that I've seen lately is if you look up in the source code, you see the HTML tag, and the language attribute, a lot of sites now, because they use trademarks, they don't have a document language. I ran across a lot of sites that don't use a document language. They're using a framework. I won't name names because I'm not out to shame, but having that attribute helps screen reader users and I think that's a big thing.

A lot of accessibility, people don't understand. People use screen readers, or other assistive technologies, for instance, Dragon NaturallySpeaking voice input. But at the same time, I’ve got to also add accessibility is more than just deaf, or blind. I suffer from migraines, migraine headaches so animation, or motion from say, parallax scrolling can trigger a migraine. Animations that are too fast, that also trigger migraine headache. You have flashing content that can potentially cause seizures and that's actually happened before where an animated GIF was intentionally sent to someone and it caused a seizure and almost killed the person.

So there's those and then the last thing on this list that I'm looking at right now, and these are common failures, empty buttons. You have buttons that don't have labels. Buttons that have Click here. Buttons need to be descriptive. So you want to have – on my site to send me something on the contact form, it's Send this info to Todd, Click here, or something similar like that.

MAE: Can you think of any, John that you know of, too? I've got a couple of mind. How about you, Mandy?

MANDY: For me, because I'm just starting out, I don't know a whole lot about accessibility. That's why I'm here; I’m trying to learn. But I am really conscious and careful of some of the GIFs that I use, because I do know that some of the motion ones, especially really fast-moving ones, can cause problems, migraines, seizures for people. So when posting those, I'm really, really mindful about it.

JOHN: Yeah, the Click here one is always bothers me too, because not only is it bad accessibility, it’s bad UX. Like HTML loves you to turn anything into a link so you can make all the words inside the button and it’s just fine. [laughs] There's so many other ways to do it that are just – even discounting the accessibility impact, which I don't want it.

TODD: Yeah, and touching upon that, I'm glad you brought up the button because I was just going to let that go [chuckles] past me. I have to say and I think it was in the email where it said, “What's bothering you?” What bothers me is people that don't use the button. If you are using a div, or an anchor tag, or a span, stop it. [laughs] Just stop it. There’s a button element for that. I read somewhere that anchor tag takes you somewhere, a div is a container, but button is for a button.

MAE: I love that. The only other ones I could think of is related to something you said, making sure to have tab order set up properly to allow people to navigate. Again, I liked your point about you don't have to be fully blind to benefit from these things and having keyboard accessibility can benefit a lot of people for all kinds of reasons.

The other one is, and I would love to hear everybody's thoughts on this one, I have heard that we're supposed to be using h1, h2, h3 and having proper setup of our HTML and most of us fail just in that basic part. That's another way of supporting people to be able to navigate around and figure out what's about to be on this page and how much should I dig into it? So more on non-visual navigation stuff.

TODD: Yeah, heading structure is hugely important for keyboard users and screen reader users as well as tab order and that's where semantic HTML comes into play. If you're running semantic HTML, HTML by default, save for a few caveats, is accessible right out of the box. If your site and somebody can navigate through using let's say, the keyboard turns and they can navigate in a way that is structurally logical, for instance and it has a flow to it that makes sense, then they're going to be able to not only navigate that site, but if you're selling something on that site, you're going to have somebody buying something probably. So that's again, where tab order and heading structure comes into play and it's very important.

JOHN: I would assume, and correct me if I'm wrong, or if you know this, that the same sort of accessibility enhancements are available in native mobile applications that aren't using each HTML, is that correct?

TODD: Having not delved into the mobile side of things with apps myself, that I really can't answer. I can say, though, that the WCAG guidelines, that does pertain to mobile as well as desktop. There's no certain set of rules. 2.2 is where there are some new features that from mobile, for instance, target size and again, I wrote another article on CSS-Tricks about target size as well. So it's if you ever noticed those little ads that you just want to click off and get off your phone and they have those little tiny Xs and you're sitting there tapping all day? Those are the things target size and dragging movements as well.

I did an audit for an app and there was a lot of buttons that were not named. A lot of the accessibility issues I ran into were the same as I would run into doing an audit on a website. I don't know anything about Swift, or Flutter, or anything like that, they pretty much fall into the same category with [inaudible] as far as accessible.

JOHN: I also wanted to circle back on the first item that you listed as far as the WebAIM million thing was color contrast, which is one of those ones where a designer comes up with something that looks super cool and sleek, but it's dark gray on a light gray background. It looks great when you've got perfect eyesight, but anybody else, they’re just like, “Oh my God, what's that?” That's also one of the things that's probably easiest to change site-wide; it's like you go in and you tweak the CSS and you're done in a half hour and you've got the whole site updated. So it's a great bit of low-hanging fruit that you can attach if you want to start on this process.

TODD: Yeah. Color contrast is of course, as the report says, this is the number one thing and let me look back here. It's slowly, the numbers are dropping, but 85.3%, that's still a very high number of failures and there's larger text. If you're using anything over 18 pixels, or the equivalent of 18—it's either 18 points, or 18 pixels—is a 3:1 ratio. With that color contrast is how our brains perceive color. It's not the actual contrast of that color and there are people far more qualified than me going to that, or that can go into that.

So what I'll say is I've seen a lot of teams and companies, “Yeah, we'll do a little over 4.5:1 and we'll call it a day.” But I always say, if you can do 7:1, or even 10:1 on your ratios and you can find a way to make your brand, or whatever the same, then go for it. A lot of the time you hear, “Well, we don't want to change the colors of our brand.” Well, your colors of your brand aren’t accessible to somebody who that has, for instance, Tritanopia, which is, I think it's blues and greens are very hard to see, or they don't see it at all.

Color deficiencies are a thing that design teams aren't going to check for. They’re just not. Like you said, all these colors look awesome so let’s just, we're going to go with that on our UI. That's one thing that I actually ran into on that SAAS product that I spoke about earlier was there was these colors and these colors were a dark blue, very muted dark blue with orange text. You would think the contrast would be oh yeah, they would be all right, but it was horrible.

JOHN: You can get browser plugins, that'll show you what the page looks like. So you can check these things yourself. Like you can go in and say, “Oh, you're right. That's completely illegible.”

TODD: Yeah. Firefox, like I have right here on my work machine. I have right here Firefox and it does this. There's a simulator for a visual color deficiencies. It also checks for contrast as well. Chrome has one, which it actually has a very cool eyedropper to check for color contrast. If you use the inspector also in Firefox, that brings up a little contrast thing. The WAVE extension has a contrast tool.

There's also a lot of different apps. If you have a Mac, like I do, I have too many color contrast because I love checking out these color contrast apps. So I have about five different color contrast apps on my Mac, but there's also websites, too that you can use at the same time. Just do a search for polar contrast. Contrast Ratio, contrast-ratio.com, is from Lea Verou. I use that one a lot. A lot of people use that one. There's so many of them out there choose from, but they are very handy tool at designer's disposal and at developers’ disposal as well.

JOHN: So I'm trying to think of, like I was saying earlier, the color contrast one is one of those things that's probably very straightforward; you can upgrade your whole site in a short amount of time. Color contrast is a little trickier because it gets into branding and marketing's going to want to care about it and all that kind of stuff. So you might have a bit more battle around that, but it could probably be done and you might be able to fix, at least the worst parts of the page that have problems around that.

So I'm just trying to think of the ways that you could get the ball rolling on this kind of a work. Like if you can get those early easy wins, it’s going to get more people on board with the process and not saying like, “Oh, it's going to take us eight months and we have to go through every single page and change it every forum.” That sounds really daunting when you think about it and so, trying to imagine what those easy early wins are that can get people down that road.

TODD: Yeah. Starting from the very outset of the project is probably the key one: incorporating accessibility from the start of the project. Like I said earlier, it's a lot easier when you do it from the start rather than waiting till the very end, or even after the product has been launched and you go back and go, “Oh, well, now we need to fix it.” You're not only putting stress on your teams, but it's eating up time and money because you're now paying everybody to go back and look at all these accessibility issues there.

Having one person as a dedicated accessibility advocate on each team helps immensely. So you have one person on the development team, one person on the dev side, one person on the marketing team, starting from the top. If somebody goes there to a stakeholder and says, “Listen, we need to start incorporating accessibility from the very start, here's why,” Nine times out of ten, I can guarantee you, you're probably going to get that stakeholder onboard. That tenth time, you'll have to go as far as maybe I did and say, “Well, Domino's Pizza, or Bank of America, or Target.” Again, their ears are going to perk up and they're going to go, “Oh, well, I don't really, we don't want to get sued.”

So that, and going back to having one person on each team: training. There are so many resources out there for accessibility training. There are companies out there that train, there are companies that you can bring in to the organization that will train, that'll help train. That's so easier than what are we going to do? A lot of people just sitting there in a room and go, “How are you going to do this?”

Having that person in each department getting together with everybody else, that's that advocate for each department, meeting up and saying, “Okay, we're going to coordinate. You're going to put out a fantastic product that's going to be accessible and also, at the same time, the financial aspect is going to make the company money. But most of all, it's going to include a lot of people that are normally not included if you're putting out an accessible product.” Because if you go to a certain website, I can guarantee you it's going to be inaccessible—just about 99% of the web isn't accessible—and it's going to be exclusive as it's going to – somebody is going to get shut out of the site, or app. So this falls on the applications as well.

Another thing too, I just wanted to throw in here for color contrast. There are different – you have color contrast text, but you also have non-text contrast, you have texts in images, that kind of contrast as well and it does get a little confusing. Let's face it, the guidelines right now, it's a very technically written – it's like a technical manual. A lot of people come up to me and said, “I can't read this. I can't make sense of this. Can you translate this?”

So hopefully, and this is part of the work that I'm doing with a lot of other people in the W3C is where making the language of 3.0 in plain language, basically. It's going to be a lot easier to understand these guidelines instead of all that technical jargon. I look at something right now and I'm scratching my head when I'm doing an audit going, “Okay, what do they mean by this?” All these people come together and we agree on what to write. What is the language that's going to go into this?

So when they got together 2.0, which was years and years ago, they said, “Okay, this is going to be how we're going to write this and we're going to publish this,” and then we had a lot of people just like me scratching their heads of not understanding it. So hopefully, and I'm pretty sure, 99.9% sure that it's going to be a lot easier for people to understand.

MAE: That sounds awesome. And if you end up needing a bunch of play testers, I bet a lot of our listeners would be totally willing to put in some time. I know I would.

Just want to put in one last plug for anybody out there who really loves automating things and is trying to avoid relying on any single developer, or designer, or QA person to remember to check for accessibility is to build it into your CI/CD pipeline. There are a lot of different options.

Another approach to couple with that, or do independently is to use the axe core gems, and that link will be in the show notes, where it'll allow you to be able to sprinkle in your tests, accessibility checks on different pieces. So if we've decided we're going to handle color contrast, cool, then it'll check that. But if we're not ready to deal with another point of accessibility, then we can skip it. So it’s very similar to Robocop.

Anyway, just wanted to offer in some other tips and tricks of the trade to be able to get going on accessibility and then once you get that train rolling, it can do a little better, but it is hard to start from scratch.

JOHN: That’s a great tip, Mae. Thank you.

TODD: Yeah, definitely.

MANDY: Okay. Well, with that, I think it's about time we head into reflections; the point of the show, where we talk about something that we thought stood out, that we want to think about more, or a place that we can call for a call of action to our listeners, or even to ourselves. Who wants to go first?

MAE: I can go first. I learned something awesome from you, Todd, which I have not thought of before, which is if I am eyeballing for “contrast,” especially color contrast, that's not necessarily what that means. I really appreciate learning that and we'll definitely be applying that in my daily life. [chuckles] So thanks for teaching me a whole bunch of things, including that.

TODD: You’re welcome.

JOHN: I think for me, it's just the continuing reminder to – I do like the thinking that, I think Mae have brought up and also Todd was talking about earlier at the beginning about how we're all of us temporarily not disabled and that I think it helps bring some of that empathy a little closer to us. So it makes it a little more accessible to us to realize that it's going to happen to us at some point, at some level, and to help then bring that empathy to the other people who are currently in that state and really that's, I think is a useful way of thinking about it.

Also, the idea that I've been thinking through as we've been talking about this is how do we get the ball rolling on this? We have an existing application that's 10 years old that's going to take a lot to get it there, but how do we get the process started so we feel like we're making progress there rather than just saying, “Oh, we did HTML form 27 out of 163. All right, back at it tomorrow.” It's hard to think about, so feeling like there's progress is a good thing.

TODD: Yeah, definitely and as we get older, our eyes, they're one of the first things to go. So I'm going to need assistive technology at some point so, yeah. And then what you touched upon, John. It may be daunting having to go back and do the whole, “Okay, what are we going to do for accessibility now that this project, it’s 10 years old, 15 years old?” The SAAS project that I was talking about, it was 15-year-old code, .net. I got people together; one from each department. We all got together and we ended up making that product accessible for them. So it can be done. [laughs] It can be done.

JOHN: That’s actually a good point. Just hearing about successes in the wild with particularly hard projects is a great thing. Because again, I'm thinking about it at the start of our project and hearing that somebody made it all through and maybe even repeatedly is hard.

TODD: Yeah. It's not something that once it's done, it's done. Accessibility, just like the web, is an ever-evolving media.

MANDY: For me. I think my reflection is going to be, as a new coder, I do want to say, I'm glad that we talked about a lot of the things that you see that aren't currently accessible that can be accessible. One of those things is using alt tags and right now, I know when I put the social media posts out on Twitter, I don't use the alt tags and I should. So just putting an alt tag saying, “This is a picture of our guest, Todd” and the title of the show would probably be helpful for some of our listeners. So I'm going to start doing that. So thank you.

TODD: You’re welcome. I'm just reminded of our talk and every talk that I have on a podcast, or with anybody just reminds me of the work that I have to do and the work that is being done by a lot of different people, other than myself as well, as far as advocacy goes in that I don't think it's ever going to be a job that will ever go away. There will always be a need for accessibility advocacy for the web and it's great just to be able to sit down and talk to people about accessibility and what we need to do to make the web better and more inclusive for everybody. Because I tweet out a lot, “Accessibility is a right, not a privilege,” and I really feel that to my core because the UN specifically says that the internet is a basic human and I went as far as to go say, “Well, so as an accessibility of that internet as well.” So that is my reflection.

MAE: I'll add an alt tag for me right now is with a fist up and a big smile and a lot of enthusiasm in my heart.

MANDY: Awesome. Well, thank you so much for coming on the show, Todd. It's been really great talking with you and I really appreciate you coming on the show to share with us your knowledge and your expertise on the subject of accessibility.

So with that, I will close out the show and say we do have a Slack and Todd will be invited to it if he’d like to talk more to us and the rest of the Greater Than Code community. You can visit patreon.com/greaterthancode and pledge to support us monthly and again, if you cannot afford that, or do not want to pledge to help run the show, you can DM anyone of us and we will get you in there for free because we want to make the Slack channel accessible for all. Have a great week and we'll see you next time. Goodbye!

Special Guest: Todd Libby.

Support Greater Than Code