Jen tells us to start accessibility today, to start with one thing. Then to do one more thing, and then one more.
Thanks to Twilio for sponsoring the transcript for this episode.
Make sure you have a look at:
- Their blog: https://www.twilio.com/blog
- Their channel on Youtube: https://www.youtube.com/twilio
- Diversity event tickets: https://go.twilio.com/margaret/
Transcript
Nic: Welcome to the Accessibility Rules Podcast. This is episode 73. I’m Nic Steenhout, and I talk with people involved in one way or another with web accessibility. If you’re interested in accessibility, hey, this show’s for you.
To get today’s show notes or transcript, head out to https://a11yrules.com.
Thanks to Twilio for sponsoring the transcript for this episode. Twilio connect the world with the leading platform for voice, SMS, and video at Twilio.com.
So in this episode, I’m continuing my conversation with Jen Luker. Last show was quite awesome, do check it out if you haven’t already, but we spoke about accessibility obviously, but also explored a little bit of the relationship between knitting and weaving and coding, and the impact that can have on helping people learning to code. So that was awesome.
So, welcome back, Jen.
Jen: Thank you.
Nic: We finished last week talking about your greatest achievement and how you built a workflow that was really monitoring accessibility at all stages of the project. From coding to checking on the live site with real data. A flipside to that, what would be your greatest frustration in terms of web accessibility?
Jen: My greatest frustration is people that, no matter how much you try to explain how it’s useful they just shrug their shoulders and say, “I don’t have time,” “It’s not important,” “maybe we will get to it in a few years.” There’s so much low hanging fruit that you can get to with just a few minutes of extra work that completely transforms the entire web if we all did it and it doesn’t have to be some big, giant initiative or an extra thing. It can be a few minutes, it could be “I’m going to think for five seconds on what to really put in this alt tag,” or it could be, “..you know.. I think I’m going to use a button instead of a Div here” or “… maybe an ARIA role will help here when I have to use this thing but, it’s not very accessible.” Just a split second decision makes a huge difference, and it doesn’t… at the moment the perspective on accessibility is that it’s a feature. And that’s so disappointing because it’s not a feature. If you couldn’t get through your funnel and buy the product, you would be flipping out making a hotfix to get it to work, right?
Nic: Yeah, yeah
Jen: But there’s a huge amount of people that actually can’t buy your product and nobody cares. Accessibility isn’t a feature. It’s a usability bug. And changing the…
Jen: Right? So, I mean, when you’re dealing with accessibility issues they’re accessibility bugs, and they’re bugs in your system. They need to be documented, they need to be fixed. Especially if they’re affecting your funnel. So I think that’s probably my hugest frustration, is trying to change the perspective from “It’s a feature we can do in a few years when we get around to it” to “These are actually usability bugs.”
Nic: Why do you think there’s this mindset of … “Oh well, it’s a feature” or “It’s too hard” or “I can’t be bothered”? Why do you think people, even after you’ve spent some time, energy and resources trying to do a bit of education … why do they keep that attitude do you think?
Jen: So, there’s some really cool tools like Lighthouse for Chrome or aXe for Chrome or Firefox and when you load it up, and you run a quick technological audit on your website, and 900 issues come up on one page… that just goes into shock overload, right? You just look at it and you’re like, “that’s one page out of hundreds so how much does that really add up to as far as accessibility problems” and, it just seems…it can be really overwhelming. It can be hugely overwhelming to look at that huge number, and realize how many problems you might have. And I think that that number is a little bit deceiving because of the fact that you might get dinged 37 times for one minor color change that would solve all of those.
Nic: Yeah, yeah.
Jen: Or, you’re dinged on not having a label in a field, and if you just modified the component that you’re using to include a label section it would solve all of the form label issues on the entire website and not just one place. So, some of those things… they tell you every single time there’s a problem even though the solution may be one place. One small item that you could do that would solve a lot of those issues. So, I think that it’s overwhelming and we’ve gone so long without really thinking about it that now that we’re thinking about it we all have brownfield projects that have been around for ages and modified and tweaked and quicked and spaghetti code, and it’s just… it’s so much that we shut down and we just shrug our shoulders and move on, and I think that it is much easier to say, “the time to start thinking about accessibility is before you start” …
Nic: Yeah
Jen: … And that really alienates the people that are like, “But my project has existed for 15 years in various renditions. So what am I supposed to do now?”
Nic: Yeah, that’s a good point because I often say that. You know? I often say you have to bake accessibility from the start of a project. But, yeah, I can see where it might be alienating for people that have had a project going for a long time but, maybe we need to start thinking in terms of… not so much the start of the project but the start of redesign or just start of implementing new features. And…
Jen: Mmmhmm
Nic: …If you can make concrete parts of a project more accessible, eventually as you redraw your entire app or system you’ll end up with an accessible system.
Jen: I like to say: Just start with today. Like, I’m sorry the rest of the code isn’t… it’s not accessible, but that’s okay because I’m going to start today. And, today I’m going to a linter on my computer that I’m going to run by myself. And any code that I write is going to be accessible based on the linter. That’s going to help everything that get’s through your door. And after that, it’s a matter of, “okay, well. Now I’m going to start applying that to PR’s. I’m going to start mentioning when I start seeing accessibility issues in PR’s.” And then it becomes more of a team effort, and everybody installs the linter. It becomes part of your process. It becomes part of [CIA and CB?07:56] at that point. And then maybe you install aXe, perhaps … aXe core as part of your, you know, selenium tests and it’s like a one-liner that you can add that then checks your components for accessibility and that becomes eventually part of your CI and with all of this also comes talking to QA and saying, “Hey I saw these issues. Can you also look for these issues when you’re testing?” and that starts to spread…
Nic: Yeah…
Jen: … and it starts with one dev doing one thing, today. And as you’re going through you fix things as you find them. You fix things as they go. And it slowly starts evolving into an accessible website over time. So, it doesn’t necessarily have to be that the entire company buys in and we’re all starting from the beginning or even starting from the beginning of a redesign. It can come from just one dev starting today.
Nic: Yeah
Jen: And it spreads.
Nic: Yeah…
Jen: And yes if you …
Nic: [crosstalk] … need that dev…
Jen: … [crosstalk] right! Need that dev. If you are… if a rewrite is coming down the pipe start bringing up the concerns. Start talking about them. Make sure those things are heard. Push back a little. It’s okay to push. And that’s a way that you can take a website that already exists and evolve it into something that’s accessible, even if it’s not today. And like I said, no one’s ever going to reach the end goal of “My website is accessible, and I’m done,” it’s always a moving target, and it’s always an evolution. So there’s nothing wrong with starting your evolution today.
Nic: What do you think is the conventional wisdom about accessibility? The one thing that everybody knows about web accessibility?
Jen: I think the one thing that everybody knows is… like HTML is inherently accessible. But, how do you take the fact that HTML is accessible and turn it into a website is accessible, especially when you start bringing in interactivity and more than one page and passing through information and … it’s easy to say HTML is accessible and it’s a lot harder to say, but how do we end up outputting accessible HTML?
Nic: Especially when nowadays so many projects seem to rely on frameworks that haven’t really considered accessible HTML output so you end up with masses of Divs and Spans that have zero semantic meaning and it seems, at least to me, that so many of the younger generations of programmers out there don’t actually know the basic skillsets of HTML.
Jen: They haven’t needed to. I mean, when HTML 5 came out a lot of those devs were super excited about it because it included a lot more definition as part of our basic HTML code base. Nothing had been just a straight Div, we had an actual header tag and a main tag and an article tag and nav tag, you know? So we had more descriptive tags, but it was kind of a weird evolution in the HTML 5 came out and then it was kind of adopted over time but by the time that it was really adopted and started gaining traction the Javascript frameworks really started taking over. And everyone just kind of dropped it.
Nic: Yeah
Jen: And it just kind of slipped by but those things still exist. They’re still there, they’re still extremely useful and a lot of the accessibility audits like Lighthouse and aXe, for instance, they tell you about those things. They tell you about the fact that you’re missing some of those HTML 5 tags which is kind of nice.
Nic: Yeah
Jen: But, with those outputs and the way that we have trained and educated the new devs we’ve forgotten this big important thing, and I think it was because HTML, with it being inherently accessible we still didn’t think about it even then. So, now that we are writing a bunch of Divs and Spans it’s a matter of remembering why the web was structured around HTML. Why we structured it that way and then why we need to think about it when we are outputting our code as well. And then train everyone. And part of that training come in the docs that you write, the examples that you put online. If you made those examples using best practices in accessibility, then it becomes a lot of copy, paste automatically accessible as new devs are learning. I don’t know about you, but that’s how I learned to code. “Oh look, there’s a stack overflow thing. Let’s just copy and paste that, modify it for what I need to make it work the way I need it to…” right?
Nic: Yeah
Jen: So, I mean, but what if that example were accessible? What if it included all the tags and everywhere you looked for an example it always included those tags? I have a story from [Niggling Hughger?13:21] who said that when she was learning to code she was surrounded by devs who also were pretty passionate about accessibility so when they would work together and write this code with her, they would always use certain tags, they always used certain formats to develop… buttons were always used for buttons and links were always used for links and so… she ended up going to a coding interview and coding, you know, whiteboard coding what it was and the interviewer was like, “wow, accessibility. That’s really cool that you care about that. And she was just confused. She was like, “What? I just thought this was how we are supposed to code it. I thought this was just how it worked.” That really blew my mind that if our examples were accessible, to begin with we would literally learn that’s just how we are supposed to do it. And it wouldn’t be a question of, “Is this accessible, is it not?” it would be a little bit more like, well that’s just how you do it.
Nic: Wow. That’d be the day.
Jen: Right? Wouldn’t that be amazing?
Nic: Yeah. What do you think the number one reason most people fail to succeed with web accessibility? Is it this sense of an overwhelming amount of stuff to do or is it something else?
Jen: I think that it’s easy to skip. It’s easy to look away and not look at it. It’s easy to just run through your quick test of what you need to do to get something to pass and then move on. I kind of like to say that the job of developers is to understand how it works. And the job of QA is to understand how it shouldn’t work. And because of the fact that the mind frame of devs is how it works we forget about the ways it shouldn’t work, we forget about our failed cases and I think that’s probably why its so difficult to get accessibility in from, like, the developer standpoint is because we know how it works for us and it works when I put in the right information, and everything is fine. And we forget about, well, what if someone were holding a baby? Would they be able to navigate their website with one hand? Or, what if they’re in the middle of a bar and they want to share a video? Would they actually be able to do it? Could you even hear the video? Maybe a transcript or subtitles would be nice. What if someone in a different country is trying to understand the things that they’re ready or English is the second language or 5th language? Or German is a second language?
Nic: Yeah
Jen: So it’s easy to forget about people that aren’t you, when you’re going through and writing code. So, I don’t think it’s necessarily a malevolent intent. I think that it’s much more forgetting. Or not thinking about it.
Nic: Yeah. In some levels, I’m wondering if I wouldn’t rather a specific desire to exclude rather than an “I don’t really know, I don’t really care.”
Jen: Mmhmm
Nic: Because it feels a lot more exclusive to not even be worth the thought than to have someone who does it on purpose and, yeah, I don’t want you here, and it’s something you can actually sink your teeth into and actually build anger around it. And from anger, you can have righteousness. But if it’s a question of “Hey you know what? I don’t even have enough energy or desire to think about the issues you might have on my website”, that’s a lot more difficult to handle I think.
Jen: Ignorance is always the hardest thing to fight. And, habit is also a very hard thing to fight.
Nic: Yes
Jen: We are having the same issue today in, don’t use guys because it’s not inclusive. And “guys” is a term that everyone uses everywhere, right? It’s just.. It’s a … and the thing that I’ve heard there is it’s just a phrase. It’s just… it’s a phrase. I don’t mean anything by it. I’m not trying to be exclusive. It’s just a phrase, and the answer to that is, no. It’s a phrase that’s been developed over time, and it’s not only… it continues to propagate the same connotations over time. And, by teaching the next generation that guys is fine, it’s the same… it’s propagating that thought process further down. And, it’s kind of the same thing with accessibility in that if it’s just not something you think about, it’s not something you know it’s not something that you even know to invest any time in. It’s harder to fight.
I mean, something people say or people will ask me, “What can I do to try and convince my boss to let me start implementing some of these deeper [tech that stories for accessibility ?” and I usually say, “one in eight men are colorblind, go find the colorblind guy in your office and take him to your boss and say “Boss, can you please explain to them why we can’t work on accessibility ?”
Nic: Yeah
Jen: And I find that knowing someone… just one person, who is affected by an accessibility bug is enough to get people to start thinking about it. Like, well, can Craig read this? Can Craig work with this?
Nic: Yeah
Jen: Craig at the office… What’s Craig’s thought on this? It becomes a person to identify with and it becomes the start of changing that thought process. Because we are so insular and we think of ourselves in our little tiny world and it’s hard to break out of that little box or bubble that we’ve developed for ourselves that finding one person that is actually affected by something accessibility related is enough to pop that bubble. It’s enough to make a door or a window in our box. And to give us a small look at what happens outside of that. And, it gives us that way to get through to bigger, and more. But it just takes knowing someone.
So, if I were to give anyone advice on accessibility it would be to find the one colorblind person in your office. Start there.
Nic: Yeah. I like that. That’s a good thing.
Jen, what do you think the greatest challenge is for our field moving forward? What do we face as an accessibility community if you want?
Jen: I think the thing we face is the continued evolution of languages and frameworks. Right now, in Javascript, for instance, we have Angular, we have React, we have View, and the further away from HTML we get the more we have to think about it. So I think the thing we are facing is, how do we develop tools to make it easier to do the right thing than do the wrong thing? Some of that is education. But, I also wonder if there aren’t tools we can start implementing to help. And, I mean, we do have some. But technology isn’t the start and the end of it all.
Nic: Do you think it’s our responsibility to ensure that all these new shiny frameworks are actually working in ways that are accessible?
Jen: I think it’s everyone’s responsibility.
Nic: Hmm.
Jen: I think everyone from the developer to the user all the way out to the person using a website. From framework creator all the way out. It’s everyone’s responsibility. And if you see something, say something. As they like to say.
Nic: Yeah.
If you weren’t doing the job you’re doing now, what profession would you like to attempt?
Jen: Triage surgeon
Nic: Why?
Jen: I am not squeamish and I love fixing things. Particularly people. In this case. Or helping people.
With growing up with my terminally ill sister there was thousands of surgeries and procedures. There were multiple organ transplants and there was always something magical about watching the body heal. Being able to intervene in a situation that might be permanently debilitating and helping make it a little bit better. Or preventing it from being so debilitating. Giving that extra chance. And often times that starts with the moment of the problem. The very beginning. When an injury happens, for instance, and doing everything you can to prevent further damage. And to try to repair some of the damage that’s been done. So…that’s what I would do.
Nic: That’s very cool.
Let’s finish off by asking you the one thing you think people should remember about web accessibility?
Jen: Start today and start with one thing… and after that one thing do one more thing … and after that do one more thing. Because Rome wasn’t built in a day but each step, each brick makes a difference.
Nic: I like that. Start today and start with one thing. Then do one more thing… yeah. I think that’s a wonderful thought to finish on.
Jen Luker, thank you for having been such a great guest on the show this week, last week. It’s been a great conversation and hopefully, I’ll bump into you at some point in the future at a conference or other.
Jen: I certainly hope so and it’s been very fun. Thank you so much.
Nic: Thank you.
Everyone out there, thank you for listening to the show. I hope you enjoyed it and if you do, please do tell your friends about it. You can get the transcript for this, and all other shows at https://a11yrules.com and a quick reminder, you can get yourselves some neat accessibility rules branded swag at https://a11y.store
Catch you next time!