Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I am Dave Rupert--Heading Level 2--Rupert, and with me is Heading Level 1, Chris Coyier. [Laughter]

Chris Coyier: I get to be Heading Level 1? Aw, that's--

Dave: Yeah, well, hey, hey.

Chris: Aw, thanks. Too bad there's no H group element to put them both inside.

Dave: Ooh, we could. We could invent that.

Chris: Yeah.

Dave: [Laughter] So, hey.

Chris: Where's the standards people here? Gosh dang-it. I'm sick of div class equals subhead, you know.

Dave: Oh, yeah.

Chris: There used to be a subhead element. Anyway, this is Episode #367 where we're going to be talking about -- I'm sure HTML semantics will come up a little bit or maybe a whole heck of a lot. We have two guests that really specialize in accessibility; one of them a longtime friend of the show, Christopher Schmitt. Hey, Christopher.

Christopher Schmitt: Hey. Hey, Chris. Hey, Dave.

Chris: Hey, Christopher. You might recognize Christopher for running a zillion conferences, as he has, or the millions of books he's written - that type of thing. Are recently at this company that's somewhat new to you, isn't it? Knowbility.

Christopher: Yeah, Knowbility. Yeah, I just started it up in January.

Chris: January. That's not too new, but pretty new, half a year there.

Let's introduce the second guest first because you both work there, right? We have Nic Steenhout too. Did I get that last name right, Nic?

Nicholas: You got it spot on. Hi, folks.

Chris: Hey! Nicolas has a podcast as well, so it's kind of a crossover episode, "Accessibility Rules dot com," a11yrules.com. You're at Knowbility, too, yes, Nic?

Nicholas: Yes, I'm with Knowbility. I've been working with them for nearly two years now. I'm the accessibility testing team lead, but I've been playing with accessibility for nearly 25 years, so it's a topic near and dear to my heart.

Chris: Yeah, fantastic. Maybe partially the genesis of this show, this would be a good show to do any time, but I feel like probably -- you know Dave probably knows a heck of a lot more about accessibility than I do. Dave was an early creator of that website. What is it called, Dave?

Dave: Accessibility Project, A11y Project.

Chris: Project, and Dave has made some pretty cool accessibility resources like those cards you made recently and stuff. I'm a little jealous. What a wonderful idea.

I know even less, and so, probably on this show, probably put my foot in my mouth a little more often than I should about accessibility stuff. It comes up pretty regularly just because how can it now when it's a show about front-end Web design and development, which is probably where a lot of accessibility stuff happens. I don't know. Maybe these guys could correct me on that if I'm wrong but it always seems to me like that's the layer at which we can cause harm and fix problems pretty regularly, I think.

Then we had a show about Scott Jehl. Not about Scott Jehl. That would be funny, though, to have a bunch of people on just to talk about Scott.

Dave: [Laughter] A show not with him, but about him.

Chris: About him, yeah.

[Laughter]

Chris: With him where we ended up probably going off on some tangents that we didn't have any business going off on, so I think maybe we can correct some of those mistakes now. Let's just spend the hour talking about accessibility, period. Can we maybe know a little bit more about Knowbility or what you two do or the type of clients you work with? Can you give me some kind of understanding of where you come about accessibility in the world?

Christopher: I'll lay down the foundation for what I know about Knowbility and then I think Nic can probably fill out the outlines a bit more. Knowbility is a nonprofit organization, so we have services and efficacy programs related to accessibility. We do commercial services like tech services like auditing and also training and helping clients with remediations. Also, we have other things like Access Works, which is a database of people with disabilities that will do usability testing, so you get real feedback on your website about how it informs.

Chris: No kidding?

Christopher: Yeah, I was listening to the Hidden Podcast that they did earlier, and he talks about doing real research with real usability testing to find out what really works and the theory about it.

Also, we have a program outreach for K-12 for teachers to teach them about accessibility training, actually accessibility technologies, and we also have a conference every year, Access U, which is a practical training conference that happens in May in Austin, Texas. That's what we do also.

I'm pretty sure I'm missing a whole lot of what else we do.

Nicholas: Yeah. Maybe I should preface that we were talking about H1, so maybe the H1 of Knowbility would be really the mission, which is to create a more inclusive digital world for all abilities. We really are looking at that overarching mission in everything we do.

Chris: Is it Web, though? Is it websites or does it transcend that?

Nicholas: it does, in many ways, because it's Web, but it's also apps. It's also PDF documents. Anything that is digital information, we really play with. Obviously, the primary thing we do is on the Web because most of the digital accessibility really is on the Web, but we have worked with people to just make sure all their documentation and resources that are available digitally are all accessible, whether it's on the Web or not.

Chris: One way you could be working with somebody is they come to you perhaps on their knees saying, "We have problems and we don't have the expertise to fix it in-house. Can you teach us to be better at it or maybe just do it? Help us make our site more accessible." Maybe they do that because they are just good people in the world and want their site to be better, or are there other reasons, too, like, "Oh, we're going to be sued, so we need your help right now"?

Nicholas: Yeah, there are really three types of clients. There are the people that know it's the right thing to do and they know they don't have the resources or the know-how to do it. Then they come to us to help.

There are the people who are aware that it is a legal requirement for them. We work with a lot of education and government agencies, so they really have that right smack in front of them.

Then we do have the odd client that comes to us and are telling us, "Hey, we are undergoing an OCR compliance, Office of Civil Right complaint, a lawsuit, and we need to get things fixed."

We work with people. Typically, we will do training to design tech team, development team, and QA teams. We do a lot of auditing and our audits tend to be a lot more than, "Hey, this bit breaks accessibility; this bit doesn't." We explain what the problem is, for whom it's a problem, how important it is, and we give specific ideas on how to fix it.

Chris: Hmm.

Nicholas: Ideally, our tools, our reports can be used by all the client's team to actually have a really good idea as to how to fix. Also, it's a learning tool so, ideally, we want them to get to a point where they don't need to come back to us all the time. Obviously, we like working with people. That's not the idea, but we also want people to learn, grow, go forth in the world, and spread the accessibility message.

Chris: Yeah. You teach a man to button and he'll click his whole life, as they say.

Nicholas: Yes.

[Laughter]

Nicholas: Yes, exactly. You do teach them, you know, buttons do something; links go somewhere. Don't use links for buttons. You teach that over and over and over again until it sinks in.

Chris: Oh, that's fantastic. Is that a simple one? Is teaching somebody a link goes somewhere and a button triggers an action, they're different things, and chances are there are some places on your website where you fouled that up? Is that Accessibility 101 or is that a big one, still? Does that fall in the bucket of a simple fix? Yeah?

Nicholas: Accessibility, there are a lot of simple fixes. The funny thing is, I started with accessibility about 25 years ago when a blind colleague came into my office. He said, "Nic, what's this website about? The only thing my screen reader tells me is, 'Image, image, image, image, image, image, image, image.'"

I had a look at the site and, low and behold, it was a site that was using images of text because they wanted fancy fonts. We didn't have CSS back then so, if you wanted something looking a little bit different than Times New Roman, you needed to use images, but they hadn't put in alt attributes for any of the images, so you ended up with the menu totally unusable for folks who are using screen readers. That was 25 years ago.

In the last quarter of a century, every single audit I've done, I have to tell developers, "Use the alt attribute. If the image is decorative, use an empty alt. If the image is informative, make sure that the alt text is clear and concise and describe the purpose of the image properly." This is ongoing, so this would seem like a fairly low hanging fruit that by now everybody should get.

Is it easy to teach that? Well, yes. But, at the same time, something in the system is broken because things that are easy to fix, the difference between a button and a link using semantic code, using proper heading hierarchy, that kind of stuff is stuff I encounter all the time.

I tweeted a couple of days ago. I said, "I should write a master accessibility report that I can give to four out of five clients because I know what issues I'm going to find in the report before I even look at the site." That was a little bit in jest, but it reflects the reality of the job we do. It reflects the reality that most people out there don't have the training, don't have the knowledge, and I blame the system for that.

How many boot camps are excellent but don't mention accessibility? How many computer science programs don't talk about accessibility or maybe they have two hours over the course of three years? If people don't know it's out there, then people won't know to do these easy to fix, low hanging fruits.

Chris: It must be discouraging in some ways and probably need to find solace in something like, "Well, we fixed it for one client site and their site is great now," so hopefully there is some satisfaction in those things. Yeah, it's a little bit of a bummer to go 25 years and be fixing the same things. I suppose--I don't know--mechanics change oil every day for 25 years too.

Nicholas: It is frustrating when you look at it at a systemic level. But when you're looking at a one-on-one relationship with clients, with developers, with stakeholders that, actually, you see that penny drop in their eye when you talk to them and, suddenly, they get it. That is so rewarding because you know that maybe you haven't created an accessibility expert but, suddenly, you have an accessibility champion in the organization. That is so much more important than having everybody being an expert.

You need people that understand how important it is and at least understand the basics because you can always reach out for an expert if you come into a gnarly thing. But if you have a champion that understands that probably three-quarters of all accessibility issues can be solved with very low entry tech solutions, it's good. The more champions we have out there, the better it is.

Chris: Mm-hmm.

Nicholas: I challenge the listeners of this podcast. Inform yourself. Read a little bit about accessibility. Become that champion in your organization and you will change the world; you really will.

Dave: I like that perspective. I've been in the accessibility stuff, game, I guess, tangentially for a while and I still don't feel like an expert, but I'm very much this advocate for accessibility, even if I mess it up.

For me, I started getting into the nuance. If you do accessibility poorly, you can actually make things worse. I hear a lot of fud about that, like, "Oh, you didn't do good enough accessibility. Therefore, you did it worse." I'm like, "Ah! I messed it up."

I agree. We need more people championing, but how do we get people the skills? Is it just through collective knowledge? How do we bring people up to up their skill level?

Nicholas: I was talking with a great guy on my podcast last year. His name is Sina Bahram. He's a screen reader user who has a brilliant mind in terms of accessibility and awareness. He works with museums quite a bit.

He said something that struck me quite a bit. He said, "We don't have an accessibility problem. We have an awareness problem." I think that really is the answer to your question, Dave, is that we need to increase awareness. We need to build that. When people become more aware, then everything else is going to flow on.

I keep going back to, we need to get curriculum at computer science programs, at boot camp, to all include accessibility. We need to build that awareness. Unfortunately, right now, what's happening is that there are a lot of lawsuits. Those lawsuits build awareness of accessibility but in a negative way.

I think it was last year. Do you remember that number, Christopher? Was it 2,500 accessibility lawsuits in 2018? Something like that.

Christopher: Yeah, it was almost exponentially higher than the year before.

Nicholas: Yeah, so that is actually quite concerning to me that there are more and more of these accessibility lawsuits. In some ways, almost -- I won't say frivolous because they do raise good barrier -- they raise good problems. You know, this site is not accessible, yes, but we want to avoid serial accessibility lawsuits as well.

We're building awareness of accessibility on the one hand but it's, I think, the wrong way to go about it. The cynical part of me thinks, "Well, in our … now in the socioeconomic background we have, that's probably the only thing that's going to make a real difference." But maybe we have people out there that are going to include accessibility in the curriculum.

I know the Center Centre is a UX school and students are getting … about accessibility in every single class rather than something that is forgotten at the end of the program. "Oh, and by the way, you should make your websites accessibility. Okay. Now you graduate. Good-bye."

If we see that happening, I think we will start having a big difference. I think. I hope.

Chris: I had somebody write in with this. They had some design thing they wanted to do on a data table with a table element, T head, T body, THTB, whatever. They wanted to do some design thing and tables are weird in HTML and CSS. They do weird layout things and there are limitations to what they can and can't do, in a sense. They wanted to do something weird and unusual.

I think they wanted rows, like headers intermingled within. You'd go down 50 rows and there'd be another T head kind of thing.

Nicholas: Hmm.

Chris: You know. It just was a design weirdness, but they wanted to do the position sticky thing. As you scroll up, that new bar would take place of the other bar. I don't even remember if this is exactly what, but it was some kind of design thing.

I think one of the solutions was, it was either to forget using table elements at all. We'll just use a bunch of divs. Just div it up and then you can do whatever you want, or we'll use table elements and then we'll reset. In CSS, you can just tell it to behave not like a table; just like something else. That was one of the two things.

It was only -- the conversation -- even in my brain, the limited accessibility knowledge I have, I'm like, "Eh, that doesn't feel right. There are reasons why the elements do what they do. There are semantics attached to them. But, more than semantics, there are literal roles." I'm somewhat aware that elements announce themselves as what they are. There's probably a certain way that a screen reader behaves when it hits those elements that is useful and expected versus a bunch of divs, which does nothing special.

Nicholas: Yeah.

Chris: I didn't even necessarily blame the person, but it was just interesting that it was the furthest thought from their mind. It was like, "What are you talking about? I just want some headers to stay where they are. That's all I want. What are you talking about?"

Nicholas: Yeah.

Chris: The awareness thing reminded me of that that they just had no awareness. It's not that they were trying to do something nefarious. They just had no idea that there was any problem with that at all. It's like you give somebody some finger paints and they paint what they wanted to. Then you're like, "I don't like your finger painting. It's problematic." They're like, "I don't know. I was just finger painting."

It's tough. I don't even know what I'm saying there. I've used this example before, too. When I first learned JavaScript, I was so excited because I could take class names and either apply them or not apply them to an element. I was like, this is the most powerful tool ever. I've just unlocked incredible design possibilities for myself. I can build tabs. I can build them in two seconds. I'll have anchor links and I'm going to pat myself on the back here.

I'm going to make the HREF for those links match the ID of the div that they're pointing to. I've made this semantic accessibility. If the JavaScript doesn't load, it still scrolls to the page with the appropriate div where there's some connection between the tab and the thing. Nice! Man, I am a good developer!

But then JavaScript will take over and, when I click on that link, instead of jumping to where it was, it'll prevent default or whatever. Then it will toggle a hide/show class on all the relevant stuff. It'll show a tab is active, and it'll show what panel is active and stuff. Through CSS then in those classes, I can design anything. I could make that an accordion. I could make that a tabbed interface. I could make that the navigation for my entire website if it's simple enough. I have all power now as a developer. Yay!

But still, to this day, I might do that. I might think about it a little harder now because I'd be like, "Well, did I do it right, though? Did I move the focus the right way? What have I done here?" I think about it a little more, but I'd still probably lean on those patterns because they do what I need them to do. I needed to build some tabs, so I built some tabs.

Nicholas: Yeah.

Chris: But I didn't use aria-current. I don't even know what roles to use. I still don't really know exactly how to do it the right way. I'd probably look up some blog posts, find some patterns, see if Dave has something in one of the cards. There are resources out there, but my muscle memory is to just do it; just change some classes.

Nicholas: Yeah. Do you know what the first rule of ARIA is, talking of ARIA?

Chris: "Don't use it"? I think I've heard that one before.

Nicholas: Yeah. Yeah.

Chris: Is that right?

Nicholas: Yeah. The first rule of ARIA is, "Don't use ARIA if there are native HTML elements that will let you do what you need to do." That is actually one of the awareness things that we come across quite a bit. We see a lot of people that, for some reason, think, "Oh, okay. My site, my app is not accessible. I hear that ARIA, the Accessibility Rich Internet Application standards, name rules, and values, will help me make my site accessibility." Suddenly, they throw ARIA on all the things. What you end up with is, actually, a mishmash of non-semantic code that actually doesn't really work.

You really should look at ARIA as something to make things better. It's like the salt and pepper in your dish. You don't want to use it as your main ingredient. It's just going to enhance the flavors.

Yeah, if you have a tabbed interface, you would want to use an aria-current attribute, and you would use the value of tab or step or page, whichever the tabbed interface looked like. That is a good way to use ARIA, but you don't want to start using divs and changing the values, the roles, and all that if you can do it straight with HTML.

Of course, how many front-end developers today really know HTML and CSS? The four of us, we've been around for a while, but baby devs that come out of boot camps and all that, they know how to use frameworks. They know how to use this technology and that technology, but they look at HTML and they don't really understand what it is.

I don't say this to be controversial. It's just a reflection of what I'm seeing when I'm dealing with clients, when I'm going to PHP conferences, even. I speak at a lot of those conferences, and the number of times people tell me, "Oh, my God. I didn't know that I needed to use the heading hierarchy in a specific way." It's interesting to see.

Chris: Is it systemic brokenness?

Nicholas: Yeah.

Chris: If you roll into a job interview and say, "I'm an HTML expert," they'll be like, "Next!"

Nicholas: Yeah, exactly.

Chris: We need somebody that knows modern stuff.

Dave: [Laughter]

Christopher: Yeah. When HTML5 was brand new and I had a talk about HTML5, and one of the things I would do to kick off the presentation, to make it more interactive and get people to stop looking at their laptops was to get a volunteer and just ask someone to list all the HTML elements that they knew. Then that was a bridge to talk about the new stuff that was in HTML5.

I think only one person went above 20 elements. This is a Web design conference, right? This isn't people off the street. It is an issue.

When you have boot camps that spend maybe one day on HTML and then weeks on end on JavaScript and frameworks, then it's not a good situation for accessibility and HTML. Allowing the browser to become--

I remember when I first started out back in the dinosaur age, one of the things I kind of railed on as a designer first, and then a Web person second, was not to use native browser controls, like native browser form elements because they were ugly. At the time, they were … ugly.

Now, I've come like 180. Why aren't we using native form elements when we do audits and stuff like that? You should definitely allow the browser to do its job.

Dave: I think that's a huge issue. The developer doesn't have the power to say no to design or something like that, so they just say, "Well, I'll solve this problem with 20,000 lines of JavaScript." I think it's a very common issue, right? Then they end up with something less accessible than the original input. Date picker is the classic example, I guess.

Christopher: Oh, God, yeah.

Dave: Even when you know what you're doing, it's confusing. I ran into the issue where the date picture, okay, I found one that I could use my keyboard on, like up, down, left, right to navigate the little table of dates. But then when I turned the screen reader on, NVDA sucks up all the arrow keys. It wants to use the arrow keys. Then you couldn't use the date picker. It just didn't work. I was just like, "What do you do?" I'm stuck. I kind of know what I'm doing and I'm stuck.

Chris: That's what I was going for with, like, what are the differences between, "Oh, you should have used a button here but you didn't," which is in the simple bucket? You missed an alt tag here or whatever. Versus something like that, which I feel like a next level difficult thing.

It feels like the accessibility issues I run into are in one bucket or the other. We have this longstanding one at CodePen where it would be nice if you didn't get tab trapped in an editor. You can use tab into the editor, but you need to use the tab key because tabs are relevant when you're programming. Well, how do you get out of that? Well, maybe we bind the Esc key to it or something.

But then, if you go back into it, shouldn't it track the cursor position and put you back where you were inside of this replicated text area? Wouldn't that be nice? It's like, yeah, I have that kind of documented. It doesn't exist on the site, but it's a hard problem.

There's a little bit more nuance to it even than that and it represents this decent little chunk of technical debt for our app to have that thing and support it and make sure that it doesn't break over time. I'm scared of it. It's in this bucket of, like, really hard accessibility problems. I'm happy to fix buttons and add alt text all day, but these harder ones makes me nervous.

Nicholas: Yeah. See, the thing is, if you focus on the easy things that you can do, the straight up HTML fixes, semantic code, use alt attributes, make sure you can go forward and backwards, you don't trap the keyboard, your forms are coded properly, and your color contrasts are okay and don't just do gray on gray because it's hell for everyone kind of thing. If you do these things, you will have solved, I would say, up to 85% of the accessibility issues on your site and, 85% of good accessibility, that's pretty damn good.

When you have the rest then, yeah, maybe it's more gnarly. Maybe it's more complicated. Maybe there's no easy, straight solution. But you have a chance to work on that. You have a chance to reach out to experts. You have a chance to actually find solutions because you know that 85% of your other issues are actually non-issues. They've been resolved because you've used the right code, the right way to do it.

Then you can ask us, the people that do this for a living, "Hey, how do I fix this date picker? How do I fix this particular problem?" Maybe there's no easy answer, but at least you know you've done the hard lifting.

Chris: Right. Right.

Nicholas: The typical 20% of effort will solve 80% of your problems. Once you're there, you can kind of take a breather and start looking for solutions.

Chris: That's a great message. I love that.

Nicholas: Yeah. Don't look at accessibility as something I have to do it all in one shot or not at all. It's incremental. You just iterate through it and you improve it all the time. Yeah, there will be things that are difficult, but the stuff that's easy, just do it.

Chris: It seems spiritually connected to the conversations around performance, in a way, where you're wasting time if you're having a day-long conversation about how fast a four-loop is. Is it ++I or I++ or whatever, when you're like, "Bro, your images aren't even optimized yet."

Nicholas: Yeah.

Chris: You're not even serving gzip headers or whatever. If that low hanging fruit isn't handled first, you're definitely not prioritizing correctly.

Nicholas: That's what it is.

Chris: Then as a part of that perf story, some companies are having performance people. It's almost become a job, in a way, just like dev-ops somehow became a job, and that type of thing. Would you like to see that happen with accessibility or are you seeing it happen; dedicated, in-house people for this stuff?

Nicholas: Yeah. See, I'm going back to this concept of champion. I would like to see an accessibility champion in every single team in every organization, somehow who has an understanding of the basic concepts. That can actually shepherd the organization through the pitfalls, fixing the low hanging fruits.

Would it be nice to have an accessibility expert, someone who really does the topic? Yeah, sure, it would be. Is it realistic to expect that to happen? I doubt it. The reality is, it is a niche field that, like performance, like security, you need to know someone who knows their stuff and it can be hard to find.

I think the major effort for an organization really should be to hire folks that are understanding of the needs and passionate about it. Then you can actually reach out to experts if you need. Of course, if you're big enough, you have a company with 1,000 folks onboard, then, yeah, it might be a good idea to have a dedicated accessibility expert.

Chris: Let's say the bar is 1,000. If your company has got 1,000 people in it, one of those thousand should be an accessibility -- [Laughter]

Nicholas: Yeah. Yeah, absolutely.

[Banjo music]

Chris Enns: This episode is brought to you in part by WooCommerce. Today, I want to tell you about three exciting updates to WooCommerce. The first one is that WooCommerce version 3.6 shipped recently and added product blocks, so you can build rich pages with blocks in sites running WordPress version 5 or higher that show products by category, best-selling products, handpicked products, newest products, and products with specific attributes, and more. Super handy if you're using the new Guttenberg WordPress editor.

The second cool WooCommerce update is the new WooCommerce mobile app for iOS and Android. You can track your store to see which products are performing best, check revenue, view and manage orders, and get real-time alerts notifying you about store activity like new orders or reviews. Be sure to search for WooCommerce mobile app on the iOS app store or Google Play today.

Finally, if you're running a WooCommerce site right now, you should check out the new dashboard for WooCommerce admin that the team released as a feature plugin. It's what's going to eventually be the default dashboard in WooCommerce, but you can check it out right now. You get all sorts of data and analytics on your WooCommerce store with a completely customizable dashboard, new reports, and a new activity panel to alert you to what's happening right now in your WooCommerce store.

If you'd like to see a WooCommerce store in operation, go check out the CodePen shop at blog.codepen.io/shop and try ordering yourself a shirt. The CodePen shop is running on WooCommerce and the shirt is one of my favorite shirts that I wear each week.

Our thanks to WooCommerce for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: Do you follow or get excited about or know anything interesting about fixing some of these problems at a platform level? It does make sense to me that somebody like Google could see problems like this and be like, "I'd like to fix this, and our specialty is fixing stuff like this at scale," to some degree.

Okay. If alt text has been a problem for 25 years, can we throw computers at it? Could the default alt text for an image somehow be AI calculated alt text or something? Does that scare you? [Laughter] Is that a bad idea entirely?

Christopher: I'll start first and then Nic can correct me. [Laughter]

Nicholas: Yeah, I'm going to correct you, Christopher. You're wrong, of course.

[Laughter]

Christopher: Okay. Yeah, so this idea actually kind of started talking with Dave because Dave was a speaker at AccessU Online that Knowbility put on a while ago. We just got around to the thought of, like, what would happen if Google just went all in on accessibility for a year?

Chris: Mm-hmm.

Christopher: Not just the browser but, of course, for us it would be the browser, but just everything that they do. Just like, "Oh, hey. We're just going to pause for a second. They'll still sell ads and everything. We'll still make money. Don't get us wrong, but we're just going to make sure everything that we do is as accessible as we can make it."

I've just been thinking about that ever since we talked about it just in terms of what would happen if Google, maybe on that scale or that systematic level that we talked about. One of the things that came up afterwards, like Becky Gibson, who is on our team, mentioned it would be really great if the browser, when someone does target=_blank, it opens a new window. That's an accessibility issue, right? People who will just click on a link and they don't know it opens a new window. That's a big issue.

It would be great if it's automatically hardcoded in HTML. The browser says, "Well, here is this little browser widget icon that's going to show up every time you do this." Google being pretty smart about it will make it so that you can install it with CSS, so it's not like a crazy thing, but you just can't, hopefully, style it away…. What other things could they be doing to make just native HTML kind of--

Chris: Yeah. I like stuff like that, right? My little example with the tabs and all I did was change some classes and stuff. You'd think some genius somewhere could be like, "You know what? You didn't do all you could here to make these accessible, but I'm going to somehow make them accessible for you because I can kind of heuristically somehow understand what's happening on this page because I, the browser, am in charge of layout, in charge of what is visible and what's not visible, and what's going on here. Maybe I can infer what's happening and just make it more accessible.

Dave: I've heard Rob Dodson and Alex Boxhall from Chrome. They've floated the idea. Maybe there's a browser setting or, maybe, if that's too intrusive, like privacy intrusive or something, maybe it's a plugin or something that you could enforce focus and just be like, "I'm a keyboard user. I know that about myself," or a tab button kind of user. "I know that about myself," and make sure there's a focus state. If there's not a focus state or something on this element, if you can determine that, enforce one or something.

Maybe we could turn some of these faux pas into options. You give people power to just enforce this all the time because I use this all the time. I require it for my browsing. I would love stuff like that, but I don't know how far away that future is and how you get dev cycles for that stuff.

Nicholas: Yeah. I have mixed feelings about the whole thing. I'm very intrigued by the possibilities. At the same time, I'm very hesitant as a disability rights activist.

One of the things I've been hearing over and over and over is, "Ah, well, maybe wheelchairs need to be better to handle steps. Maybe we need to have assistive technologies interpret images," and that kind of stuff, which really puts the responsibility for accessibility on the person who needs it.

I have a problem with that in principle. I think things should be universally accessible and work.

Can browsers start detecting focus states or not? That would be awesome if they did, but that comes down a little bit to this concept of accessibility widget. You make a site that's really badly coded. You slap a widget on top where people can increase font size, change the contrast, and whatever, but if the site had been coded properly in the first place, that widget wouldn't exist. That responsibility on getting the individual to fix things wouldn't be there. I think, and maybe I'm dreaming a little bit, but I think that it would be nice if everything was working the right way.

The other aspect to that is, AI shows a lot of promise but it's just not ready for primetime. How long has YouTube been providing automated captions? I think it's 10, 12 years, something like that, maybe longer, even. Yet, to this day, the def community refers to automated captions as craptions. It is crap.

Dave: Oh, wow.

Nicholas: It's actually not usable for primetime. Every time I have an encounter where someone says, "Oh, well, AI is wonderful. We're going to use AI and then that's it," I'm just wanting to pull my hair out. The number of podcasts out there that don't have transcripts is mindboggling. When I talk about that, they tell me, "Oh, okay, well, it's too expensive. It's too difficult," or whatever the reason is. Then they say, "I know. I'm going to go use an automated transcription service."

I'm actually, right now, analyzing seven different well-known automated transcription services. I've got to tell you; I'm laughing at the outcome because, if I weren't laughing, I would be crying. It is not usable.

AI, yeah, it shows promise, but let's not think about it right now because, until it actually performs a minimum of 98%, 99% of the time, we can't rely on it. If we can't rely on it, we've just created barriers more than provided a solution.

Chris: Yeah. I just listened to this, the podcast, the Hidden Brain. It's a good one, an NPR one. They just replayed a show called The Lazarus Drug, and there was a concept inside of it called Moral Hazard, which I was hearing about for the first time that I thought was fascinating, which had to do with, you're a football player and there's this amazing new helmet that comes out that protects your head even better. The result of that can be that you just hit harder.

Nicholas: Hmm.

Chris: If you're a drug user and you know that the people next to you have a medicine that can bring you back instantly from a drug overdose that the temptation is to maybe push the limit of how much drugs you're willing to…. Because this Lazarus Drug exists, and you give it to somebody and, boom, they come back to life. It's incredible.

This Moral Hazard argument plays itself out in all kinds of stuff. I wonder if it even applies here, in a way, that automated solutions to accessibility problems got much better than they are now that the temptation would be to play even faster and loser with it because--I don't know--computers will fix it. You know?

Nicholas: Yeah. I like the idea of pushing the envelope, you know, go beyond, evolve, and get better design and get better coding because, if we don't evolve, we stagnate. We even go backwards, so I'm not against evolution, but I do think there's a risk there. If we rely on that, "Oh, well, if I write [explicit] code, the browser is going to fix it," well, then what's the incentive for writing good code?

Chris: Yeah, there's danger there, for sure, it seems like. You fix something at scale. You think you're helping the world. It turns out, long term, you hurt it in some way. That would suck.

Nicholas: Yeah.

Christopher: Also, it's the nature of the browser to be forgiving, too. We work in a medium that is forgiving but, also, we have to be mindful of how we code in order to enact these; make sure where code is accessible, semantic, and meaningful. That's the beauty, the power, and also the curse of the Web.

[Banjo music]

Chris Enns: One of the challenges faced when launching your very own startup, business, or personal website is getting a domain name that is available and relevant to what you do and has high recall. If you belong to the tech industry like many of the ShopTalk Show listeners do, it's ideal for you to use a .tech domain name. A .tech domain name will make a strong tech positioning for your tech website.

Over the last four years, many brands, startups, and programmers have adopted the domain name. Brands such as Viacom, Intel, and even the world's largest consumer electronics show, CES, committed to representing their brand on a .tech domain.

If you're a programmer working on a passion project, blog, or personal portfolio, or you're an entrepreneur building a tech business, go secure your .tech domain before someone else gets to it. Head over to go.tech/shoptalk or the link in the description and get yourself a 90% discount on one- and five-year domain registrations. That URL again is go.tech/shoptalk and use coupon code SHOPTALK at checkout.

If you're into tech, you ought to use .TECH Domain.

[Banjo music]

Chris: Is the word; is the data right or whatever? I feel like I kept hearing, the last few months anyway, that some studies came out. The big WebAIM report was the big one, I think, right? That seemed to indicate that things are worse now than they've ever been. Is that the case?

Nicholas: Nah. No, mate. Things are worse now than they have ever been. The only difference is that we are now having the tools to track how bad the situation is.

Chris: Okay.

Dave: It's the same bad. It's just….

Chris: It's just….

Dave: It's not worse. It's the same bad, okay, now.

Christopher: Well, also, you're talking about the WebAIM one million pages report.

Chris: Yeah, sorry. I didn't mean to misinterpret that or deliver misinformation. I wanted just some clarity there.

Nicholas: Yeah. Yeah. That is fine.

Christopher: Also, I want to get to the point because that report was based off of automate testing. I'm not sure we talked about automated testing and how much that catches versus how much it doesn't catch.

Chris: That would be an interesting topic, if you have things to say there. Yeah.

Christopher: Yeah. Nic probably has a fair percentage of how accurate, but I always hear 20% to 50% of automated tests catch.

Chris: Twenty! It could be as low as 20%. You run this test. You feel good about it because it says there are some contrast issues here.

Dave: Raincheck….

Chris: You fix those.

Christopher: Before I started working here, I felt good about it. Now that I started working here, I don't feel good about it.

[Laughter]

Nicholas: A couple years ago, a U.K. government department decided to write the worst accessible page on the Internet. They wrote a page that had 157 accessibility issues. Then they pitched that page against some of the better, most reputable accessibility automated testing tools. The most performant site identified 37% of issues, which means there were 63% of things that can't be identified.

Now, we're keeping in mind that this was the best performing one, so you have tools that did catch only about 20% of things. Maybe you want to use a variety of accessibility testing tools and maybe, maybe if you're lucky, they will have overlap and some differences in what they catch or not. The bottom line is, there is over half of the issues that will never be captured by an automated testing tool.

I think we have to be careful here with accessibility testing tools. I don't really like them as the only solution to the accessible journey, but they're also very powerful. If you have a site with 300 pages or more, and you want to get a feel for the kind of patterns of issues you have, use it on a beta testing tool to just capture that. Use automated testing tools in your development cycle, so you don't need to do a full audit all the time but maybe, for each sprint, you send that against an automated testing tool.

I think it would be fair to say that if your automated tests return dozens of issues, you're likely to find a hell of a lot more stuff out there. If your testing tools return maybe one, two, three issues per page, you might be in better shape than you think.

Chris: Hmm, it's like reflective of a whole, in a way.

Nicholas: Yeah.

Chris: Yeah.

Nicholas: It's a good way to get a pulse of things but, obviously, we see sites and we have two or three issues return. Maybe that's duplicate IDs or whatever.

Chris: Sure.

Nicholas: Then you start digging and you realize that they've used divs without negative tab index for all elements, so they are not keyboard focusable and that kind of stuff.

Chris: You can kind of understand, too, how an automated tool can't necessarily tell that you used a button wrong.

Nicholas: Yeah.

Chris: It sees a button. How does it know how you're using it exactly?

Nicholas: Yeah. It can tell you easily, do you have the alt attribute on an image? Yeah, but it can't analyze the image to tell you whether or not it's decorative or informative.

Chris: You should have, right.

Nicholas: Looking at the context, the same image can have two different purposes, yadda-yadda-yadda.

Chris: Right. I thought of that right away when I thought of the AI thing. I'm like, if the browser is injecting alt text onto your decorative image, you'd be like, "Hey, don't do that. I left that empty on purpose."

Just because this show, as we often talk about JavaScript and front-end development in general, whatever modern frameworks are, but let's just think Ember, Vue, React, all of that world, it's kind of pointed at sometimes as being the ushering of those in is reflective of a drop off in accessibility. The sites that use frameworks like that, they don't have to be that way, but just broad strokes, they'd bad for accessibility.

I think people say that's because it's just so damn easy to write div … clicking them, you know, JSX or whatever, and React kind of encourages you to write in that format. Is that true or is that a false dichotomy? I'm not even sure if I used that word correctly, but do you see that?

Nicholas: Frameworks, I find them very frustrating a lot of the time. I'm not pointing the finger at anyone in particular, so what I'm saying is quite a generalization but, in general, the people who build these frameworks don't really have accessibility in mind. They don't understand the importance of it and they don't understand the mechanics of it. As a result, it's not baked in.

Some frameworks, Angular has had some interesting accessibility plugins. It's like you put it in after the fact. It's like if you're baking a blueberry muffin and you try to put the blueberries in after the damn muffin is baked. It's not going to work.

If a framework was built with accessibility in mind from the get-go where all the documentation, all the examples, everything would actually take accessibility into account, then people using these frameworks would actually have a good reference to use and replicate rather than you build something and you realize, "Oh, it's not accessible. I'm being sued. Let me try and find a plugin for this particular framework that will improve things," but it's not going to be easy. It's going to be expensive.

If you'd done it right from the get-go, you don't have increased costs. You don't have increased resources or efforts to do.

Chris: Yeah. Client work wise, do you see people coming to Knowbility saying, "Hey, we have some accessibility problems. Check out our site," only to find that it's a framework that has caused the problem, in a way?

Nicholas: Very often. Very often. You start looking at the first page of an audit and you see all the classes prefixed with NG-, you know you're going to find problems on the site.

Chris: Wow. Okay.

Dave: Just to dispel some myth-busting, it's not inaccessible because it relies on JavaScript. I know a lot of people draw the line. They're like, "Oh, if I turn off JavaScript, it's a blank page." Where do you sit on that fence?

Nicholas: This is a historical thing. It used to be that when you used JavaScript, your site was not going to be accessible. For a lot of accessibility … that have been doing that a long time. I used to load sites and links just to see how it behaved without JavaScript.

The thing is, JavaScript is not the enemy here. You can actually use JavaScript to make things more accessible, but you have to keep in mind that things need to work without JavaScript because, for whatever reason, you still have people that access the Web without it.

It's not necessarily the tool itself. It's how you use it. If you use a ten pound sledgehammer to try to put in a thumbtack, maybe it's not the right tool, but you might be able to do what you need to do if you handle the tool properly. The same thing with JavaScript. It's not evil in and of itself. It's just how it's being used.

Chris: I'm just always of not two minds; I just feel like there are two pictures to paint. One of them is this very clear one that there is obviously problems, like there are demonstratable, clear problems. There are clients coming to Knowbility saying, "Our site is a problem. We use this framework," and you, having looked at endless of these sites, can identify a pattern there. That can't be argued against, I don't think.

The potential of them, I tried to tie it to my example I've used throughout this show is these little tabs hiding and showing classes. If instead of me writing it myself, instead reached for some prebaked tabs component that did the same thing but it just was written by somebody else, there was a community plugin to do that or whatever. I don't know if plugin is the right word. In React land, it would be a component, you know.

Nicholas: Yeah.

Chris: There are guys out there. I know guys like Ryan Florence who are like, "I'm going to make a tabs component. I'm going to call it reach tabs, and I am going to do everything I can to make this an accessible version of tabs." Then, if my muscle memory instead became, "I'm going to use those instead of me just handcrafting and just hiding and showing some classes," that, in that isolated case, it would be a net gain for accessibility because I've used an accessible solution that was already out there. In that sense, the framework kind of helped me, or is that not--?

Nicholas: Yeah. It is absolutely true if we had more libraries out there that actually were fully accessible. Then it would be better. But it's a little bit like JavaScript frameworks. Why do we have so many of them? Because people think, "Hey, I can do better," and there is this proliferation.

There is a new tool and a new tool and a new tool and the new tool after that. The developer out there having to actually find their way through what's going to work best, it can be difficult. First, having the library available is a problem. Then finding it is also a problem.

That's where it's going back. I go back to this awareness thing. If framework developers were more aware, then they could build that in. Then it wouldn't be a problem of finding that one library that makes great accessible tabs. All the libraries that would make tabs would be accessible.

Chris: Yeah. That's great. I see what you mean there. Yeah. There's potential but, next week, there'll be some new library and it won't have thought of the same things.

Nicholas: Yes. Yeah.

Chris: It's not so baked into our psyche that we can be sure that the next library will have learned from the last library's mistakes in this regard.

Nicholas: Yeah.

Dave: Maybe this is a good one to go out on. I think Marcy Sutton did a JS Conf talk. She's in the sphere of JavaScript, works for Gatsby, even, but she had a post called Accessibility is a Civil Right, and a talk that goes with it. That's a big statement because that gets into human rights and everything.

I personally am fine with moralizing the issue of website accessibility is a moral issue. I think, kind of back to just everything, our auditing tools don't quite catch enough. It takes a high level of knowledge and skill to test a site and fix a site.

If accessibility is a civil right, how do we close the gap on the 97.8% of inaccessible websites? It's hard for me to reconcile, like, everybody is messed up and you have to do it or else you're a bad person. How do we close the gap on being totally inaccessible to helping people?

Nicholas: Yeah.

Dave: That's sort of how I want to ask that question.

Nicholas: First, I have to say I totally agree with Marcy. Accessibility is a civil right, is what it comes down to. How do we close the gap? I actually don't know. If I knew the answer to that, I would actually probably be rich and have fixed the Web.

I do think that there is, as I said--I sound like a broken record--awareness issues. But there are these perspectives that, yeah, accessibility is a civil right. Accessibility is the right thing to do. Beyond that, if you're running a business, and I would argue that in today's business environment, any dollar you make is a good dollar. If you miss out on it, it's bad. Look at the buying power that people with disabilities have. One American in four has a disability. One in four, that's 25%. Sure, not all disabilities out there have accessibility issues on the Web, but it's still a significant minority.

If you're cutting out, say, even half of that, say you're cutting out 12% of business right there because your site is not accessible, whether or not it's the right thing to do, whether or not it's a civil right, it doesn't make any business sense either. We have to think about that.

Then, of course, there is the legal requirements that, hey, you know what? Your site has to be accessible by law. Again, that comes back to the civil rights. There are laws around the civil rights as well.

How do we make all these sites that are not accessible, accessible? Well, right now, for us at Knowbility, it's one site at a time that we help people improve the situation. It's on Twitter doing advocacy. It's building awareness out there and, hopefully, eventually, it's going to sink through.

Going back to what I was talking about earlier, let's try to improve accessibility tuition in all the places where people learn about the Web: computer science, tutorials, boot camps, that kind of stuff.

Dave: Christopher, do you have any thoughts?

Christopher: Yeah. I have to echo that. I think one of the editions of my CSS Cookbook I wrote was, I had just a chapter on how to write semantic Markup just because I wanted people to write semantic Markup because then their CSS is cleaner and leaner. Did I have to write a chapter about HTML in my CSS Cookbook? No, my editor probably would have liked it if we didn't put it in there, but I just felt like it was important to put it in there and make sure people know that, to apply CSS correctly and cleanly, you would want to have clean HTML. That's just one place to put it in the education where people learn.

Yeah, going forward, just start with the simple things and the simple things start growing into bigger things. One of the things we could talk about on the way out is also just the lowest hanging fruit for accessibility improvements, right? The biggest problem in the Web 1 Million Project that was found was the color contrast. I'd just encourage everyone who is listening just to check out their website, their personal blog, and just say, "Hey, is my color contrast issue correct? Do I have any issues with that?" If so, just correct them and deploy it to the website and you've made one small step forward.

Dave: Robin Rendell says, "Make the design system better one percent at a time.

Christopher: Yeah.

Dave: Just trudge forward. Cool. Well, thank you all so much for coming on. We should probably wrap up the show. I could talk a million minutes about this stuff, but I really appreciate your time. Nic, for those who aren't following you, how can people follow you and give you money?

Nicholas: Well, I have Twitter, which is @vavroom. I'm on Patreon at patrion.com/steenhout. Of course, my podcast is a11yrules.com. I invite folks to come check out the Knowbility website as well. That is knowbility.org.

Dave: Awesome. Christopher Schmitt, how can people follow you and give you money?

Christopher: I'm on Twitter as well. It's @teleject. My website needs work, but it's at Christopher.org. Also, you can see me at Artifact Conference, which I'm one of the cofounders there, so we will have Elle Waters there speaking about accessibility as well as some other great speakers like Dave and Chris.

Chris: Hey!

Dave: Hey! Come on down to Austin town.

[Laughter]

Dave: All right, well, thank you all so much for coming on. Again, this is near and dear to my heart, very timely, as I stare down 300 accessibility issues in my client's backlog, so I really appreciate it.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month.

If you hate your job, head over to shoptalkshow.com/jobs and get a brand new one because people want to hire people like you.

Chris: People like you.

Dave: Chris, do you have anything else you'd like to say?

[Laughter]

Chris: Footer, ShopTalkShow.com, close footer.

Dave: Role, content, info.