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 frontend Web design and development. I'm Dave Rupert and with me is Chris Coyier.

Chris Coyier: Hey! That's right. We've got a classic show with a fantastic guest, a firs-time guest on the show, Heydon Pickering. Hey, Hayden. How are you doing, man?

Heydon Pickering: High/low.

[Laughter]

Heydon: Sorry. I messed that one up already. I was going to say, "Hi," and then I was going to say, "Hello." You know when you do the same thing? I'm going to go with, "Hello."

Chris: Oh, good.

Dave: All right.

Chris: We'll take it. You know the third time is a charm. No, but, really, it's wonderful to have you on the show. Heydon does all kinds of interesting things on the Internet that you've probably seen. One of my favorites, it's hard to pick a favorite, really, but Heydon has what he calls a design pattern library trying to be a blog or a blog trying to be a pattern library, one or the other. Either way, it's called Inclusive-Components.design, which is kind of a wonderful resource for looking at common patterns and, I guess, how not to screw them up, things like tabs, cards, and things like that, as well as a really cool YouTube channel that you should be subscribed to called Making Future Interfaces that is really high quality videos explaining some ways that the Web works these days.

Anyway, there's more than that. Maybe I'll pass it off to you, Heydon. What's up, man? Tell us. Tell us stuff.

Heydon: Hey. Hey, Chris, and, hey, Dave. Yeah, a real pleasure to talk to you both. Yeah, so I've actually written down a few general notes so, if a topic comes up, then I'll remember to say certain things about it.

Chris: [Laughter] Sure.

Heydon: One thing I didn't write down was anything to do with myself, and this is always something I do. When I do a conference talk, I never do the section at the beginning where I talk about me because I always don't quite know what to say. I also kind of like the idea of getting up, talking about something, usually something kind of random anyway, and then just leaving and people thinking, "I wonder who that person was."

[Laughter]

Dave: Sure.

Chris: You know what's weird about this show is that we're not an interview show anyway, really. Sometimes it comes across that way because we have a guest on, so I like people to know who they are. Kind of our roots are just answering questions of people. I don't know. It morphs over time, but we don't have a pile of questions for this episode because there'll be enough stuff to talk about anyway. You know we're not really an interview show, but still - but still, let's talk about you just for a minute. It'd be nice to hear.

We even briefly talked about, before the show, how everybody has a different way into this industry. It sounds like yours is a little unique. I have no ideas what it is.

Heydon: Oh, yeah. First of all, I suppose when I was very young, I wanted to be a stuntman, but then I quickly discovered that I didn't particularly like being punched or thrown out of helicopters.

Chris: Hmm.

Dave: Ah.

[Laughter]

Heydon: That was conjectural. I didn't get thrown out of a helicopter and then think, "No, this wasn't for me after all." I decided that I didn't want to try it, basically. It's the feeling in your chest. You know that kind of anxious feeling you get when you're flying downwards very, very quickly, and so I gave up on that idea fairly, fairly early on. I only really made it to throw myself out of a couple of trees and slightly taller, like maybe two stories.

Chris: Two?!

Heydon: Then moved quickly on from that and I got into art and design. I think a lot of people who get into music and they're very creative, a lot of musicians, especially in the accessibility community, who started out doing music and doing creative stuff, doing art stuff, and then moving more into technology and finding the Web as a really great way of expressing their ideas and also pointing people towards things they've done so that they can sell them.

I got into digital art, I suppose, because I wanted to make album covers and things like that. I think I was using Corel photo paint, which I stuck to for a long time despite the fact that Photoshop was the thing that everyone kind of wanted me to use just because I was more used to it. It didn't have this sort of layer thing where you had to choose the layers individually. You just basically moved stuff around.

Chris: Mm-hmm.

Heydon: If you clicked on something, it came to the forefront. I kind of found that nice and simple to use.

I went to university, and I studied something called digital media. That was basically a cross between photography and other digital stuff. I learned how to make a website in Dreamweaver, like an early version of Dreamweaver when it was still owned by Macromedia.

Chris: Sure. Yeah.

Dave: Mm-hmm.

Heydon: [Laughter] The website was a spoof of a British television show called "Art Attack." There's this children's television show called "Art Attack" and there's a guy called Neil Buchanan. It was the late '80s, early '90s so, naturally, he had a mullet.

Chris: What a great name, "Art Attack."

Heydon: Yeah, exactly. It was very aggressive, very in your face. Yeah, so he would do these art attacks where he'd go around and create these large artworks spontaneously out in the wild, you know, in a park or on the side of a building or something like that.

Chris: Gosh, how great. I've never heard of this. A British show, obviously, and the logo looks like Double Dare, Dave. There's splotchy--

Heydon: Oh, did you find it? [Laughter]

Chris: Yeah, I like live Googling, of course.

Heydon: [Laughter]

Chris: You were into it, yeah?

Heydon: I mean I guess being at university age, I felt I was a little bit grownup for it by then, but I kind of like doing satirical and spoofy type things, so my first website was a parody of Art Attack called "Dart Attack" and the idea was that this guy, Neil Buchannan, would go around with a set of darts, like you'd play darts in a pub, and throw them at people instead.

[Laughter]

Chris: That sounds like a college project. Yeah, yeah.

Heydon: Yeah. Actually, that got a better grade than some of the stuff which wasn't sort of violent or nonsensical, and so I never really understood that. But, yeah, it was like a Dreamweaver thing that it was made out of. You had the table thing where you actually visually pulled to the sides of the cells around to make it kind of into the right shape. Then when you actually viewed it in a browser, it will collapse back in again and it never really works. It was that kind of thing, so just colored cells in those primary colors that you saw in the logo.

Chris: Yeah.

Heydon: Just darts everywhere, pictures of people with darts in their head and lots of blood and that kind of thing.

[Laughter]

Chris: That was like your first website, or at least a strong memory of an early website you made.

Heydon: Yeah, I think that was either my first or a very early one. Then the other thing, going back to the music thing, is that I would make websites just to kind of promote music that I'd done and say, "Go and find it here, or go and buy it here." I got a reputation for being quite good at hacking MySpace pages, so some of my early paid work was actually kind of making MySpace pages look good somehow, and I learned a lot about HTML and CSS in the sort of dark arts of pulling that stuff around when you don't actually have the code base. Kind of like the Zen Garden thing where you have the set HTML and then trying to make it do interesting things with CSS.

Dave: I think MySpace customization, that and Neopets, you could kind of hack Neopets, right? I think a lot of people have come into our industry via those two sort of hacking formats.

Heydon: Yeah, absolutely.

Dave: I don't think you're alone.

Heydon: Yeah, I think you either come from a formal background, I guess, like a computer science sort of background, or you are kind of a creative person who thinks, "Oh, the Web sounds exciting. I can do things here and then, suddenly, I've got an audience." I think that's what draws people like me is, if I can learn this newish medium with code and everything, then I can translate what I'm doing in my bedroom or whatever into having it somewhere where people around the world can view it. That was just really exciting.

I know that you've covered this on this show before, and I really enjoyed listening to the conversation you had about it. There is this sort of tension between the formal computer science-based kind of way of doing Web stuff and the much more laisser-faire, creative, it's okay to hack things thing. You know?

Chris: Yeah. Yeah.

Dave: You had a post about this, right? I'm trying to remember the whole post from memory.

Heydon: [Laughter] I certainly can't remember it.

Dave: The gist was, through your consulting work. That's the kind of work you do, is that right, consulting work? You kind of hop into companies and you find out no one knows how to do the accessibility. Then every is kind of overworked as a full stack developer.

Heydon: Ah, yeah.

Dave: Is that right?

Heydon: Yeah, it was the problem with a full stack thing. Yeah. I've had a lot of experience with this recently where, yeah, you get these individuals who were just given all the code to do. It's weird that we think of code in and of itself as being a profession. If you can write (SQL) "sequel" or "squirrel" or whatever you call it, then you'll be able to write CSS, but they're completely different tools. They both just happen to be digital tools which involve browsers and HTTP.

Chris: Mm-hmm.

Dave: Yeah, it's like speaking Spanish and Chinese.

Heydon: Yeah, absolutely. Yeah.

Dave: There might be no crossover, but there's no much.

[Laughter]

Heydon: Yeah, but it's even more divergent than that, I think, because at least Spanish and Chinese are both a means to a similar end, as in communicating the same kind of stuff, whereas CSS, despite the fact that you are writing code, the product is a visual thing to do with form and layout. SQL, I don't even really know what SQL is.

Dave: Well, it's stuffing data into spreadsheets.

Chris: [Laughter]

Dave: Stuffing text into spreadsheets, yeah.

Heydon: It's Excel, isn't it? Yeah, basically. Yeah.

Chris: I guess, of course, that's a problem if somebody who is given a job can't do the job proficiently, right? That could be any combination of jobs ever. I don't go to my doctor and ask him to fix the sink or whatever, right? The actual problem part comes in when nobody does that, the doctor/sink thing, right? The full stack thing does happen, and it happens a lot and you're seeing it a lot. That's where the problem part comes in.

Heydon: Yeah.

Dave: I love the doctor/sink problem.

[Laughter]

Dave: It's good.

Heydon: Actually, that doctor analogy I've used in the past to try and basically convince people to listen to their designers. When I say designer, I mean very broadly; not someone who just does graphic design, but someone who does research, does interaction, and does the accessibility end of things as well on structure and whatever.

The idea of going into a doctor and him saying, "Well, I'm diagnosing you with a sprained ankle," and then you saying to him, "Actually, I think I want to go more with diabetes." [Laughter] Then him sort of being like, "Oh, okay, fine. It's diabetes then." That's how we seem to communicate with this whole stakeholders and designers. That seems to be the relationship where, ultimately, designers capitulate, even if it's something really absurd. Trying to empower designers to be a bit more, actually, "I know my job is important."

Chris: It's kind of interesting how this all dovetails into each other. We got you. You're young, university-ish, and making parody art attack websites, clearly into art and music, and come to the Web for various reasons to promote your music and that type of thing. Then the Heydon of today is interesting in that you have all this accessibility experience and write about that, consult about that and whatnot, and have websites that are clearly art focused like your mutable.gallery, which is just, "Look at art that I've made." There are two sides of you. There's still this, "I'm just a hacker making art, whatever," and this accessibility person and this educator person.

Dave: Historically, art websites and music websites tend to be the least accessible, so I'd love to hear how you married that.

Heydon: [Laughter] Yeah, that's true. They win all the awards, don't they? Then you try and actually use them or even just load them on a reasonably average network and all hell breaks loose. Yeah.

Chris: Where did that part come from, your desire to think excessively and deal with accessibility, if that's not a natural transition from art and music, which maybe it was?

Heydon: Okay. Yeah, so I don't think there is as disparate interests as they might seem because, with the accessibility thing, when I started to see how many mistakes we were making in terms of not taking into consideration, just broadly speaking, how differently people interact with websites and Web applications, suddenly, my job, overnight, just became more interesting because, up until that point, my concerns were really, I suppose, I just thought about, "Does it look good? Is it easy to ready?" that kind of thing, but not the much broader kind of discipline of inclusive design and all of the different considerations that come into play.

Suddenly, I was met with this thing where I thought, "Oh, actually, this needs to be rethought a lot, and that just means there's more for me to think about. There are more problems to solve. There are more opportunities for me to be creative."

Quite selfishly, I delved into accessibility and into inclusive design because it made my life more interesting. Now, I know that it's obviously a good thing to do and it's a good process to go through and a good mindset to have when you're designing to actually think about the people that you're making stuff for, which seems ludicrous that people don't do that. Yeah, quite honestly, it was just that it opened up opportunities to fix more things and so I felt more useful, in a way. I felt more validated.

Chris: It's kind of great. It shows a little bit about your personality because, if you can think of, "Oh, there are lots of different people that all use the Web in different ways and that your reaction to that is, "How fun! Wow! This is a lot more interesting."

Heydon: Yeah, exactly. Yeah.

Chris: Where a lot of people are like, "Oh, shucks. That sucks."

Heydon: I do find it really weird that folks tend to go, "Oh, no, that's something extra for me to think about," and I think that's probably because they're really enamored with other parts of our discipline or whatever. I try not to call it an industry. I try not to think of it in terms of business, so there is Web discipline, Web community things, stuff we do, whatever it is.

There'll be people who don't want to think about that because they're really interested more in the kind of optimization side of things and how neat they can write their code and the latest flavor of programming or whatever. That's kind of what keeps them interested. Actually, that to me is all a means to an end so, personally, it doesn't interest me that much. It's the point where the human meets the interface is what I find interesting, I guess.

Yeah, it was a joy to think, "Oh, so there's so much here. There's so much more to fiddle around with and kind of calibrate to work better in different ways."

Chris: Then only to discover that that's somewhat of a rare opinion to have. Maybe not. I rarely hear people argue against accessibility. You mostly hear about just people screwing it up or whatever.

Heydon: Yeah.

Chris: Most front-end developers, including myself, are like, "Of course, it's a good idea," and, yet, are still guilty of screwing it up.

Heydon: Everyone screws it up. I screw it up as well. It's like anything else. The key skill to have is to be able to change your mind or to accept that things are not as you presumed they would be. When you encounter a situation where it's like, oh, there are a lot of people who just wouldn't be able to use this because of the way it's designed." We need to walk it back to a more kind of primitive version of itself, which is much simpler, or something like that. Instead of just kind of going, "Do you know what? We've made it this way and we're excited about it. We're just going to plow ahead," or if there's any way that you can't accept that you've made mistakes.

I think, generally speaking, this is where we go wrong as a species. It's not so much that we make mistakes. It's the fact that, once we've made the mistakes, we pretend that they weren't mistakes. Then we carry on as we were. Brexit is a good example of that.

[Laughter]

Heydon: Yeah, I said I managed to shoehorn some Brexit stuff in, didn't I? Yeah.

Chris: [Laughter]

Heydon: Yeah, it's this thing of--

Dave: It was part of your contract. We had to allow it.

Chris: You resorted to clickbait recently to get some people over.

Heydon: [Laughter] Oh, yeah. But what was funny about that, and this says a little bit about, I guess, privilege, was that people clicked. To explain, I did a blog post where I think it was Facebook withdrawals React, I think, was the title of it. Then loads of people frantically clicked on it. Then I had a lot of people go, "Oh, okay. That's clever. Nice one," because what it was, it was trying to get people to sign this petition to revoke Article 50, which is basically the whole Brexit thing, as it turns out, is a huge mess being handled really badly by an incompetent government, but also based on illegal and fantastical premises. Therefore, we should probably just call it off. The idea was that we were trying to get as many people to sign this petition and it got up to over six million people sign this petition.

I got a lot of feedback from people where they were writing to me saying, "Oh, wow. Okay. You really scared me there. I really thought that I couldn't use React anymore." I was like, "Well, yeah, okay. I'm happy for you, but my country is literally -- we are going to be [explicit] in plastic bags within the next two or three months so, like, priorities, I guess. [Laughter]

Dave: Yeah. Yeah, I'm sorry to hear about your framework.

[Laughter]

Dave: Sorry you were troubled about your framework, but I'm about to lose free travel across Europe.

Heydon: Exactly. Yeah, exactly.

Dave: Yeah.

Heydon: [Laughter]

Dave: Yeah, that's funny.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by Discover.bot. Discover.bot is an online community for bot creators designed to serve as a platform agnostic digital space for bot developers and enthusiasts of all skill levels to learn from one another, share their stories, and move the conversation forward together. Discover.bot was built by Amazon Registry Services and it's an informational place for novices and experts in the bot development space. Discover.bot regularly publishes how-to guides and the latest bot building resources. Some recent guides are how to design a bot personality, how to set up payments through your bot, and how to stop shopping cart abandonment.

Discover.bot also shares expert advice and provides insights on all things bots. For example, what KPIs are worth measuring, why emojis may be breaking your bots, and how to write an engaging chatbot dialog. They cover all sorts of topics and genres including bot development, bots for business, chatbot news. If you're new to the bot development space, Discover.bot will teach you everything there is to know about bots. There's a guide called Beginner's Guide to Bots, which will teach you how bots were invented, the basics of how bots work, what bots can do, and where bots are developed and published.

If you've already got a few bots of your own, Discover.bot can help you choose a framework that's aligned with your business, for example, e-commerce, travel, finance, hospitality, and more. They've got a great guide just for you called Guide to Bot Building Frameworks. From NLU features to platform connectors to APIs, there's a lot to consider. Find out what all the major frameworks have to offer so you can choose a chatbot framework that fits your objectives.

To find out more, go to Discover.bot/shoptalk so they'll know you came from us and check out Discover.bot. Our thanks to Discover.bot for sponsoring the ShopTalk Show.

[Banjo music]

Dave: It keeps nagging me. You said you call it a discipline and not an industry. Why? What is that? Is there a reason?

Heydon: I'm not sure if discipline is the right word, but I think of the Web as just being a public good, just a public service, and I think that the professional developer-ization of it is a bit sad. I mean I'm a professional developer or designer for the Web, or whatever you want to call it.

Sara Vieira stated doing this whole campaign, which is, let's make the Web [explicit] again, and did this silly website with all of the gifs and everything like that. She's fantastic. It got loads of attention, blew up like two different servers that she put it on because it was so popular. I think people really are kind of bored with things getting kind of a bit sort of stayed, a bit repetitive, a bit same-y, and just a bit sort of corporate, I suppose.

When I go to Web conferences, I only accept invitations to conferences where I know they're kind of community conferences because I like to be around people who are just passionate about it. They're not in it to -- I mean they're in it. They make money out of it. It's their living, but people who just want to make things for the Web because it's fun and it's a chance to be creative. It's a chance to help people and to reach people, so conferences like Frontiers and Beyond Tellerrand.

I think we should be having -- it's almost like bringing people together like in a church. I mean I'm an atheist, but the idea of it being where people will come together in one place and they're just all good people in one place. You could do a lot of good together. As it turns out, we end up talking about the finer points of CSS or whatever, which is a very specific, technical concern, but when you get all of those people in that place, I've made strong friendships with people who aren't very aligned with politically and culturally in different ways because those conferences are places as meetings of minds and passions rather than just, here is where we will learn stuff which will make us money.

Yeah, whenever someone is kind of business-y, for instance on Twitter, I can sort of tell straightaway and I know I won't follow them because I know that there's going to be a lot of self-promotion or promotion. We all do that to some extent. We have to.

Chris: Yeah. Sorry about that.

Heydon: [Laughter] No, I mean I do it as well. [Laughter]

Dave: I cover this in my book. It's $9.99….

[Laughter]

Heydon: Yeah. You know, to level the balance, if you like, I can read you a negative review from my book, which was quite fun to receive. It is … amazing.

Chris: The book is "Inclusive Components"?

Heydon: Yeah, so the book is "Inclusive Components." It started off as a website. The idea was that it was it was different. Each post was kind of recreating different common kind of pattern or component that you'd get in your design system, on your website, or whatever. As Chris mentioned at the beginning, like a tab interface, a carousel, or whatever.

With the carousel one, I had a little joke at the beginning of the article. I'll just bring it up on my browser. It says, "Carousels or content sliders are like men. They are not literally all bad. Some are even helpful and considerate, but I don't trust anyone unwilling to acknowledge a glaring pattern of awfulness. Also, like men, I appreciate that many of you would rather just avoid dealing with carousels, but often don't have the choice, hence this article."

Chris: [Laughter]

Heydon: I thought, you know, that's kind of a fun way to introduce the article. It's kind of punchy or whatever. I started getting complaints about this but, obviously, these complaints were from men. I don't know if they knew that I was a man. I think, as a man, especially as a man, I'm kind of entitled to criticize men, especially since there's a kind of get out clause there, which says that not all men are bad.

I got an interesting -- I wouldn't say it was a review. It was more of a kind of DM from someone. It's several paragraphs long. Towards the end it says, "Look, I can't fix you, but I can forgive you. You've got to overcome your own demons. We've all got them. Just because you're male doesn't mean you're a dickhead. You don't have to act like the negative stereotype you've been fed by our society. Being a man means admitting to your mistakes and trying to make better. At least that's what I was taught when I was growing up. Anyway, I forgive you and I'm leaving now. "Inclusive Components" is still pretty good despite the one hateful joke. I hope one day you can shed off the hypocrisy and become as good a person as you aspire to be. Good-bye."

That's, I guess, a review. The thing is, if you take away all of the stuff about, "You're attacking me as a man," or whatever, and you just get the bit about the book, it says, ""Inclusive Components" is pretty good," so I'm taking that as maybe, I don't know, three and a half out of five or something like that.

Chris: [Laughter]

Heydon: For a review.

Dave: Yeah. Pretty good.

Heydon: Yeah, it's pretty good, like, "You're hateful and I think that you are struggling with demons, and your hypocrite, et cetera, but on the other hand and after all, it is about the book in the end," so yeah, I'm pretty happy with that.

Chris: A solid review. Sometimes it takes a while. He needs an editor, maybe.

Dave: Yeah, that's a good reminder to never tell a joke on the Internet.

Heydon: Oh, wow. Yeah. Yeah. Well, I talk about comments and things. There's another one.

I did an article on Medium. People always complain that I'm writing stuff on Medium because it's kind of more ephemeral. Now they've started doing this thing where you can only read so many articles and then you have to sign in and pay something, or something like that. Have I got that right?

Dave: Yeah, they put up a big pay wall.

Chris: It's a little unclear to me, too. What the algorithm is that decides you're going to get the pay wall is a little unclear.

Heydon: Right. Yeah, I'm not sure either.

Dave: Every page gets a, "Hey, you like Medium?"

Heydon: Oh, gosh, yeah. [Laughter]

Chris: They even have a dating analogy they use. Isn't it like, "Let's make it official"?

Dave: Let's make it official.

Heydon: That sort of whimsical language that people use. When you haven't got an actual copy editor who knows when not to make weird, creepy jokes. [Laughter]

Chris: Yeah.

Heydon: Actually, you've just reminded me. Have you ever seen the film "Cool as Ice"? It's a 1991 film, which is like a vehicle for Vanilla Ice.

Dave: Mm-hmm. Yeah, he rides a motorcycle around. I'm pretty sure I've seen it, but it's not one that stands out.

[Laughter]

Heydon: No.

Chris: It seems like it'd be.

Heydon: I'm an '80s, '90s kid, but I don't remember watching it the first time around. I just watched it on Netflix because they did a riff tracks version of it, like where they talk over it and make jokes.

Dave: Yes.

Heydon: It was weird because I think cultural attitudes have changed so much for the better since then. Vanilla Ice just played this kind of weird, toxic, masculine character. He saw this girl that he fancied whilst driving a motorcycle. She was on one side of this white fence and he was riding his motorcycle. She was going alongside on the horse. Of course, if you're near horses, you don't want to be revving a motorcycle engine anyway because it will scare them.

Then, to get her attention, he launched the motorcycle over the fence into the field next to her. The horse rid up, and she fell off the horse. Then she said, "What the hell are you doing?" Then he said, "What the hell is your problem?" In the rest of the film he stalks her and steals her personal possessions.

Sorry. I'm not sure how this is relevant to what I was about to say but, in any case, that is a terrible, terrible film on so many different levels. Yeah, I hope I never watch it again. Anyway, so making jokes on the Internet, as you say, Dave, is a bad idea.

I wrote an article on Medium. I put it on Medium because I wanted it to be ephemeral. I didn't want very many people to think of it as being sort of like cannon for me. What was it called? CSS: A New Kind of JavaScript.

Chris: Hmm.

Dave: Yes.

Heydon: Then there were people -- most people kind of got the joke and thought it was kind of fun but also it was saying something maybe about the relationship between CSS and JavaScript and all of that kind of stuff. Obviously, there were then people who just thought that I thought that CSS was a type of JavaScript. There was a comment on something I wrote. "CSS is a declarative subset of JavaScript," specifically was one of the statements. [Laughter]

This guy comes in and goes, "No, it isn't. It has nothing to do with JS at all and existed before Web scripting languages were standardized."

I thought, okay, he hasn't got the joke but, if I'd like, I can kind of slowly maybe help the penny drop by sending him a few replies. The next reply I wrote was, "I've been writing JavaScript since 1992, and I can assure you that CSS is a JavaScript API."

[Laughter]

Heydon: He wasn't buying that either, so his reply to that was, "Considering JS was invented in '95, I somewhat doubt that." I thought, "Okay, I'm still not getting anywhere. I'm going to just go for broke," and so I wrote, "To be fair, I was writing Java in 1992 and later compiled it to JavaScript in 1995, but it's the same basic underlying logic."

Chris: [Laughter]

Heydon: [Laughter] "That's just how codebases evolve sometimes. It's how XML became Xcode, for example."

[Laughter]

Heydon: His reply is, "LOL. Okay, buddy," like, oh, yeah. Yeah, right, man. Like that.

Chris: Oh, that's nice. That's nice.

Heydon: …come up to someone and say, "Check it out. I'm a giraffe."

Chris: It means you win. I think of Jenn Schiffer any time I think of stuff like that because she always was the first person to retweet anybody that got sucked in by her, any satire she wrote, and it was absolutely glorious.

Heydon: Yes. Yeah, she is the master.

Chris: That's the whole point of writing satire is to get the person who didn't get it.

Heydon: Yeah, that's trolling. I guess that's trolling to some extent, yeah.

Chris: I know, and it's a little April Fool's Day-y and not everybody appreciates that kind of thing. But when it's so over the top, "XML turned into Xcode."

Heydon: Right, yeah.

Chris: If you're taken in by that, it's just like too bad.

Heydon: Like some of the stuff that Jenn writes is like, how can anyone possibly think that this is earnest? Yeah, she is absolutely the master. I think we probably got a similar sense of humor.

This trolling, and there's good trolling and there's bad trolling, I think. People will say, "Oh, you're trolling." To them, that's always a negative thing, but I don't think it necessarily is. It's like situational art if it's in a good way.

Dave: Yeah. Satire is a form of criticism.

Heydon: Yeah.

Dave: It is, right?

Heydon: Yeah, yeah, exactly. I mean there's trolling where you're actually harassing or bullying or kind of making light of serious subjects of diverting attention away from what is an important thread or whatever. That just ranges from nuisance to borderline criminal.

Then there's trolling, yeah, which is actually just kind of having fun with discourse and kind of subverting things. I think that has its place so long as you're not too much of…. Sometimes I cross that line, but I try not to. I try not to offend people.

I did do the one a while ago. It was the Flexbox Holy Albatross thing.

Dave: Yeah, this is your follow-up album to the lobotomized owl, which, congratulations. A second hit. That's really hard….

Chris: Yeah.

Heydon: [Laughter] Yeah, and it's always something to do with birds, and I don' t know why. I don't know why it's birds.

[Laughter]

Heydon: In that article, I said, "You can solve this kind of container query problem with JavaScript." Then I go on to say, "But the problem with JavaScript is that it may not run. It may be blocked. It's not as well supported because it was something to do with resize observer, and it gives you cancer."

[Laughter]

Heydon: In the comments, I got a lot of people. The thing is, I'm on the fence here because I think what I said was maybe a bit offensive. Not offensive, but it could have been perhaps slightly triggering for some people because they may have been going through that or they may know someone who is going through it.

Then I thought, it's such a ubiquitous thing, cancer. It's like making jokes about death. People say, "Oh, don't talk about death," because it's inevitable and it's everywhere kind of thing. I don't know. I was kind of on the fence.

But in any case, to address people's concerns, I changed it from saying, "JavaScript gives you cancer," to saying, "JavaScript makes you bleed profusely from an anus." There, by doing that, I was no longer offending people who may be suffering or dealing with cancer.

Chris: Yeah, not so widely. I feel like if that's the case for you right now, you're probably not reading a lot of blog articles because you're more busy mopping.

Heydon: [Laughter] Yeah, exactly. Exactly. I thought, yeah, it's probably a rarer condition but, also, it's more factually accurate in terms of the side effects of JavaScript, anyway.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by NativeScript. NativeScript is a great way for front-end developers to start building native iOS and Android apps. You might have heard about NativeScript on ShopTalk Show before, but this time they've got some exciting news. NativeScript now officially supports Vue.js for app development. If you're a Vue developer, you can now build native mobile apps using the same framework you use on the Web while leveraging the power of NativeScript to tap into powerful mobile APIs. You can try it today at NativeScript.org.

Of course, they've got support for Typescript, CSS, and popular frameworks like Angular as well. NativeScript lets you build awesome mobile apps with technologies you already know. You can start coding today with the NativeScript Playground, which is a 100% Web-based resource to help you get started in minutes. Then the NativeScript CLI is there for you when you're ready to take that next step. They've got a great tutorial on their website and then you can also get started playing with some sample apps like an animated search, a login form, music streaming apps, social fitness trackers, swipeable cards and animations, charts, tab bars, restaurant menus, flight booking UIs, movie listings. There are ones that show how to build a Tinder-like swipeable card UI, putting a native dialog box in front of the user, animated rotating menus, carousels, et cetera, lots and lots of stuff to check out.

Be sure to visit NativeScript.org to get started today. Our thanks to them for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: That's a fun one. Maybe we'll get to the albatross in a minute because it's fun to talk about. I have this, just because we were talking about inclusive components, tabs, and stuff. I have this one stuck in my mind. It's a fascinating article. It's almost a long read to get through that whole tabbed interface article because there's so much stuff to consider. There's responsive design stuff. There's keyboard events and then a whole intro of how you would start, describe them semantically, and all that. It's a lot, isn't it?

What's been going through my mind, if I can just hijack this for a moment, is that I've thought, written, and this has resonated, this concept with people in the past. Let's say you're this designer that has learned HTML and CSS and is having some success with that and wants to start getting into JavaScript a little bit. Maybe this isn't as applicable these days because JavaScript is so ubiquitous everywhere, but maybe three, four years ago there were more people in this boat that they're like, "Gosh, I need to make JavaScript part of my repertoire."

I was like, "Well, why don't you check out class list or, if you're in jQuery land, just learn about toggle class. Have that be the one thing you learn. Learn how to query for an element and then turn a class on or off." It's so empowering because you already know HTML and CSS, and you know that if you apply one class to something, it applies to those styles. You take it away; those styles go away. You apply a different class, maybe the different styles on that class apply. Wow. I think something clicks in people's brain. Now I have way more control over this page than I did before, especially if I can then attach that class name adding and removing to an event like a click or a tap or a scroll event, or something like that. How empowering. I can learn three lines of JavaScript and I have it.

What that opens up, maybe for worse in my case, was that, why would I reach for some prebaked tab solution when I can do it myself? I can make three anchor links, and I'm a semantic knowing type of dude. I know how to do this right. I'm going to make those anchor links point to a hash link to a div further down or a section further down that has a matching ID so that these are links that point to the right place.

Go me! I've done it. I've made these semantically perfect, now, so three anchor links. Then I'm going to display none all of them. Then when you click one of them, it can find the appropriate thing and apply a class like active, and active will display block the correct one. Now, I've made tabs. I've made them semantically perfect.

Done. Look at me. I write three lines of JavaScript only to find out later that, holy crap; there's no correct ARIA roles being used here. I didn't think about keyboard events at all. There are a million things I forgot about. I felt empowered. I felt like I was doing it correct, only to learn, years later, I was almost doing the world a disservice in a way because I didn't think about the ten other things that tabs had to do here.

I don't have a point with all that. Maybe my point is, read Heydon's article here about tab interfaces.

Heydon: Well, no. No, no. I want to stop you there because, first of all, you've done a lot of good things for the world. I think we can agree on that. Second of all, it's kind of actually really -- I'm really ambivalent about tabs and I'm really ambivalent about the ARIA in tabs, to be honest.

In my version of it, the inclusive components version of it, it does the ARIA stuff, but there are a couple of little hacks I put in there as well because the ARIA stuff doesn't actually play particularly well sometimes with some types of screen reader and screen reader mode. If I were building an interface and I had control over how the information is laid out, what's hidden, what's not hidden, and what's interactive, I probably would avoid tabs altogether.

Just recently, and this is since I wrote that article and then, later, wrote the book, and the book is kind of like the articles, but updated, I started doing some work with the BBC in the U.K. They have their own tab interface, which was kind of set out in terms of, this is how it should work, but it was set out at a very high level. There was no advice in terms of how to code it.

I thought, "Okay, I can do the ARIA thing and do the arrow keyboard events as well," so you go into a tab and you use your arrows to switch between the tabs rather than the tab key, et cetera. Then we went back and forth about this a little bit. The BBC being a really huge organization, they're able to do lots of research. We just weren't confident that that was actually the right way to do it despite the fact that it was considered the kind of canonical version where you have the ARIA and the arrow navigation, et cetera. I made three different versions of the tab interface, one which I think is a legitimate way of doing it, which is like you described, Chris, which is that actually they're kind of the same page anchor links, which link up to the different panels.

Chris: Right.

Heydon: The only way it's really different from just linking to different sections in the page is that it shows and hides the panels. One version was kind of like that. No ARIA stuff. No custom key bindings or anything like that.

One was the full ARIA thing, as set out by the ARIA design practices, whatever that document is where it tells you how to do your ARIA and interaction stuff. Then one which was kind of a compromised position where it didn't do the arrow key navigation, but it did have the semantics there and so, yeah, it was somewhere in between. We did two full days of watching different keyboard users, so we're all keyboard users, obviously, but I mean people who depend more on the keyboard, people who can't or would prefer not to use a touchpad or a mouse.

They all completely disagreed over which one they preferred. As it turns out, there are some difficulties in some places, so lots of people just didn't find the arrow keys, so that was kind of a red flag. It's kind of an ergonomic way to interact with something but, as it turns out, even though that's kind of a familiar pattern for a native application, like a Windows application where there are tabs, you're kind of used to doing that there. People don't expect that in a webpage. They expect it to be much more simple. They expect it to be basically headings and links.

They didn't know it was there. At least a couple of the participants just didn't find it, so they never actually made it to the other tabs because they didn't even know they were present, or at least the partially sighted or blind users, in any case, because they couldn't see them either. As it turns out, the same page link version of it, the idea was, when you clicked on a tab, it would also send focus to the panel--

Chris: Right.

Heydon: --which is a big no-no in terms of the official ARIA pattern. The idea is that your space is--

Chris: Is it really?

Heydon: Yes.

Chris: You just make it appear. You don't actually send focus there.

Heydon: Exactly. The idea is that because you've designated the arrow keys for selecting tabs, the tab key then becomes or tab and a shift-tab becomes your way of directly going from the active tab into the panel and back. It's ergonomic as long as you know that that's how it behaves and you know what a tab is.

one of the participants spent the whole time going, "Oh, tags. Yeah, I get it. Tags, yeah, okay, okay." Then at the end we said, as you do in these sort of sessions. Obviously, it's not their fault, but they were saying "tags." They thought we were talking about tags. They thought the interface was a tag interface, with a G.

Chris: Yeah.

Heydon: [Laughter] That's one of the great things about research is you think you're going to find out some of the creases that you have to iron out with your interfaces. Actually, what you end up finding out is, ultimately, everyone does things totally differently, understands things totally differently. Everyone is completely disparate and the only way, only hope you have at all of making--

Chris: Is actual testing.

Heydon: [Laughter] Yeah, is finding out, well, is ensuring that things are so simple that it's difficult to make critical errors. It turned out in this case, there was this compromised version that was quite good because they kind of got the tab, or even if they thought it was tag, kind of metaphor, but they preferred to have the focus moved for them because, otherwise, the arrow keys wouldn't be found. It seemed to be a one tab interface kind of thing.

In the book version of the blog, I've updated it. I've stuffed that chapter full of caveats and do research with your users and see how they interact with it. Try that in context, et cetera.

Honestly, if I was going to do any kind of open/close, show and hide thing, thing, I would probably use something much more like an accordion because it's just the interaction is simpler. You go to a heading or a handle, you click it, and then the next thing in focus, the next thing in the source is there.

Dave: It shows up or it doesn't.

Heydon: Yeah, exactly. It's much easier to make responsive as well. A tab interface isn't a tab interface if the tabs are on top of each other. That's not how filing cabinets work. That would be weird.

Dave: Yeah.

Heydon: Yeah.

Dave: It's a good point. I have a friend Dan who works at Texas School for the Blind and Visually Impaired here in Austin, Texas. He actually is in charge of procuring technologies for kids. "We want to use Google Apps? Okay, let's run it through all the tests and see if our kids can even use it."

He's doing really cool work but one thing that he's kind of illuminated to me is even these kids, and I think just screen readers in general, are just people in that there's even different levels of technical proficiency among people and the same among screen reader users. Not everyone uses it the same and not everyone is super savvy like, "Oh, that was a tab. Oh, okay. I didn't know I could open that."

These are things you see. We are Web developers, so I sort of assume we are very experienced with tabs, but if you have ever watched a screen share on somebody, a client or from your office, doing a PowerPoint or something, it's painful to watch, right?

Heydon: [Laughter] Yeah. Yeah.

Dave: You're just like, "Click that thing! Click that thing!"

Heydon: It's very difficult not to help, isn't it, because your natural instincts is to help and tell them how to do it. It's kind of like a Columbo thing where he does that trick where he kind of gets them to admit their guilt by telling them, "Oh, so you did it like this?" Then, eventually, they go, "No, I did it in a much more clever way," or whatever. It's that kind of instinct to get involved, isn't it?

You're absolutely right, Dave. We started using terms like we would say -- I mean, I guess most businesses, when they do research, they talk about power users and non-power users. That intersects with every kind of different way of doing things as well. You have power keyboard users and power screen reader users, and there's non-power people that are screen reader users. We found that, yeah, then non-power screen reader users, they can navigate between headings and they can use it the up and down arrow keys to go paragraph-to-paragraph or just element-to-element. They'll use the tab view to focus interactive elements.

They will know little more than that, maybe, in terms of what's on offer from the screen reader. There is an awful lot of offer from the screen readers. Obviously, you can do all sorts of different kind of interactions and shortcuts with most of the main screen reader software.

Then, yeah, you have people who, "Oh, I know what a tab interface is," but usually they would be someone who is, in some way or another, technical, a developer, or something like that themselves because, of course, being in accessibility like myself, you will meet people like that who are screen reader users who then know how screen readers work because they're more involved and they understand the underlying technology a lot more, too.

Because they're close to us, obviously we take a lot of advice from them. It's still valuable advice because it helps us to understand how these things work. But, at the same time, we have to accept that most people are not as savvy as us in terms of how the Web works, in general, but then there are non-savvy screen reader users as well, for instance.

Chris: Hmm.

Heydon: Yeah.

Chris: Well, that's interesting. [Laughter] You don't often think of somebody that uses a screen reader and aren't particularly good at it.

Dave: Yeah. Yeah, you've got to factor them in, or even braille readers. I think all of us can be like, "Yeah, I know what a webpage being read to me is like. I can kind of close my eyes and imagine that." You think about a braille reader where it just presents. There's eight piano keys and then a little dynamic braille input that just prints out one line of text at a time across the page.

Heydon: Yeah. That's a whole other paradigm.

Dave: It's different.

Heydon: [Laughter] Yeah.

Dave: Right? I have no frame of reference for it.

Heydon: Then you get a switch accessibility where it's literally just one button, which you can use to do various interactions.

Dave: Mm-hmm.

Heydon: It's like this really minimalist way of interacting with something. Yeah. [Laughter] It's a difficult thing to get your head around. Going back to what we were saying before; that's what makes it interesting, I think.

I think, also, what were kind of stumbling up on a little bit is this difference between what's accessibility and what's inclusive design. I've tried to kind of pinpoint that on several occasions. I think the idea of making something work with a screen reader is technically, I suppose, in the terms of the Web Content Accessibility Guidelines, WCAG, it's not broken like it's not communicating information to a screen reader is one thing. That's kind of making it accessible technically is not doing what it should. [Laughter] Then that technical element is one thing, but then you have to think, well, is it actually intuitive? Would you expect this thing, which is being communicated correctly to a screen reader to even be here? If it is there, should it be next to this other thing? Does it make sense in the context of the page? Is the behavior of it expected for what else is going on, and all of those kinds of concerns?

That's much more the kind of broader, woollier, more tacit, inclusive design thing about actually how people think about things and trying to make it as intuitive and simple as possible.

Chris: Think about people who get things locked in their head because it feels like this is happening to me all the time throughout my career is that now there is some canonical resource for something like a tabbed interface, or maybe you'd hope that it's not that, but I think people reference inclusive components for that.

Heydon: Hmm.

Chris: Just give me the pattern. I want the pattern. You know?

Heydon: Yeah.

Chris: Even though, if you tell them to their face, "Please do the testing. That's what really matters." It's not the only one out there. There are other resources that kind of tell you how you should do something. People like to be told what to do.

Dave: Wasn't it Scott O'Hara just posted the dialog element isn't actually really accessible to all?

[Laughter]

Heydon: Yeah.

Chris: Oh, gees.

Heydon: Scott is really good at drilling into the kind of technical shortcomings of some of these things and finding really good workarounds. Yeah, he's really good at finding those things and covering them.

Chris: There's got to be a balance between that nuance of--I don't know--don't get any particular pattern locked into your mind as the perfect pattern for this because there maybe never is one and that everything is complicated.

Heydon: Hmm.

Chris: To the point, like, don't use that as an excuse to not try to do a good job because there is no right answer. There are still lots of wrong answers.

Heydon: Absolutely.

Chris: Anyway, I think of things that get locked in people's mind. There was this Lyza Danger article a long time ago that was like, "Don't use Ms for media queries because there is a bug in how some browsers handle pixels for media queries."

Heydon: Oh, yeah.

Chris: It was my canonical example of this because it was so perfectly written and explained that it just locked into the developer consciousness that you are not allowed to use Ms for media queries. Maybe it was the other way around. It was, don't use pixels. Apparently, it has faded from our consciousness a little bit.

Heydon: I think that, yeah, there was a bug. I think maybe it was REMs, actually, but yeah. There was some offset issue thing. Yeah, I remember the one you mean. Yeah.

Chris: It had to do with zooming or whatever. It turns out that that was a lot of years ago, that problem is totally gone, and you don't need to worry about that anymore. Still, if you use one in an example, you'll get a comment that says, "Don't you know? You're not allowed to do that," which I think of. You post a blog post that uses some pattern that is against something that's locked in people's mind that you're not allowed to do, it's just funny that you'll get called out on it without any of the nuance. It's just, "Nope, you've used the wrong pattern," boop, alarm.

Heydon: [Laughter] Yeah, actually, because I know this is one of your favorite subjects, Chris, is the SVG. Along similar lines, there was a thing that came up on Twitter. Someone was sharing this thing, and it was a photograph of their folder of images, like the icons. They're all in SVG, but they all had the 200x200.svg and then 192x192, or whatever. [Laughter]

Chris: Oh, yeah! This is the size of this particular SVG.

Heydon: I got into the conversation with these people in this thread, and they were all absolutely adamant that there is a pixel grid, a universal pixel grid which, regardless of whether you're using a SVG or using a raster graphic, you have to line it up onto that pixel grid, so you have to have specific special dimensions for these things regardless of the fact that SVG is vectors and, as you perfectly well know, [laughter] scales automatically. I said, "No, the S stands for scalable." They're like, "Yeah, I know, it is scalable, but it still has to fit with the pixel grid."

I think it was Terence Eden who wrote a little while ago, which was a brilliant article. It was basically, there's no such thing as a universal pixel grid. He talks about all of the different screen pixel geometries, and they're not even square like a raster will be sort of divided into square blocks when, in JPEG, they're kind of like grouped or whatever.

Chris: Yeah. Not that I forgive anybody necessarily, but I think there is a concept of not lining things to a pixel grid, like in Photoshop. You can accidentally make a vector in between two pixel lines and it ends up kind of blurry or whatever.

Heydon: [Laughter] Yeah.

Chris: That's kind of an origin image problem. It doesn't translate to the Web so directly.

Heydon: No. Yeah, exactly. Yeah. Yeah, but they will go on, probably, for three or four years or the rest of their lives believing this is a thing. This is going back to what we were saying before about this.

Chris: It locks into your mind.

Heydon: [Laughter] Yeah, this fundamental problem we have as a species which, once we've decided something, we're too embarrassed to then go back and say, "Do you know what? I was wrong."

Chris: Are you making a Brexit analogy again?

Heydon: [Laughter] Yeah. Yeah. Yeah, exactly. Then we do this double down thing, don't we? Actually, now I'm going to be even more committed to the idea of this fantastical universal pixel grid despite the fact that….

Chris: Yeah, I like that you brought up the double down. The double down is really a plague, isn't it?

Heydon: Yeah.

Chris: I totally am susceptible to it.

Dave: Nope. It's great. I'm sticking to it.

Chris: I know.

Heydon: Yeah.

[Laughter]

Chris: It makes me even more convicted. It's so wild. It's just a thing.

Heydon: I'm really bad with that as well.

Chris: I'm sure I have it too.

Heydon: Oh, yeah.

Chris: You question me? You're questioning me?!

Heydon: [Laughter]

Chris: Oh! Oh! You better not!

Heydon: [Laughter]

Chris: Anyway--

Heydon: Yeah.

Chris: Yeah, Sara Drasner was saying -- I can't even remember the context, but she was talking about SVG in that way, too, and she was talking about the scalability of them. She used to be like, "Yes, scale, it's the first word in the acronym. Come on." People were like, "Sara, nobody knows that."

I'm like, "What?!" I feel like that was the number one talking point of SVG always. I only have ever read a blog post that didn't start with something about SVG that didn't talk about the scalability.

Heydon: I saw your talk. I forget. It was one about SVG, obviously, and you did a good bit at the start was like, "Okay. Before we get into all of the kind of like other neat stuff about SVG, first of all, it's scalable." That's fantastic. That solves so many problems. Yeah. Yeah.

Chris: Yeah, right. If that's the one thing it did, it would be cool.

Heydon: Yeah, exactly, even if you didn't have all the other filters and all of that stuff. I actually call SVG Sara Vector Graphics a lot.

[Laughter]

Heydon: Because Sara is a real sort of SVG maven, as in Sara Drasner, but then also you've got there Sara Soueidan as well.

Dave: Yeah.

Heydon: It seems that all of the Saras, anyone called Sara is just really good at SVG.

Chris: Yeah. Yeah. Yeah, I always think of Amelia, too.

Heydon: Oh, yeah.

Chris: As being encyclopedically about all the niche stuff too. I have a book about SVG. I feel confident in my ability to use the basics of SVG, maybe only slightly above average of your average front-end developer. These days, it has, fortunately, kind of seeped into most people's toolkits, thank God.

I, for the most part, feel almost helpless when it comes to complicated nuanced stuff with SVG. I am not an expert in the way that somebody like Amelia is. I know firsthand because I've hired her to do interesting little things. I know this is possible. I know it.

The stuff that gets me is when you kind of nest SVGs and you're like, "I want this part up here to be scalable in this way or it stretches horizontally but not vertically, and I want this little piece over here to not stretch at all because it's like a corner or something, this piece to stretch vertically, and all that interesting stuff." She'll be like, "Here are seven ways to do it." I'll be like, "What?!"

Heydon: Yeah.

[Laughter]

Chris: That's something else.

Heydon: I think we can agree that all of the A's in Scalable Vector Graphics should probably stand for Amelia, given her prodigious knowledge of SVG, yeah. She's like Steve Faulkner with accessibility. There's nothing that they couldn't really tell you if you wanted to know something and you ask them. Obviously, try not to bother either of them too much.

[Laughter]

Heydon: They will know and you'll be like, "Oh, okay. Cool. Thank you."

Dave: Thank you. Sorry. We're kind of going over time here. I hope that's okay. We just wanted to wrap up with some accessibility. The recent WebAIM Million came out. It's kind of a shocking study where 98% of all websites are inaccessible even through automated detection, like running it through Lighthouse and finding an error.

I just wanted to get your thoughts. How do we break out of that jam and is it a fault of ARIA? Is it ARIA's fault? Is it too hard to make an accessible website? Or is it the developer's fault? Are we failing?

Heydon: Yeah.

Dave: I'd love to hear your thoughts on it.

Heydon: That's a really good question, Dave. I think, to just touch on the ARIA thing, one of the things I think it found, if I recall correctly, is that the more ARIA was detected on the page, the more likely it was to be inaccessible, which is kind of -- [Laughter]

Dave: Yeah, inverse of what you hope.

Chris: You hate to read that, though, right? Then you're like, the easy takeaway from that is, "Oh, good. Screw that. I will never use one again, then, thank you very much."

Heydon: Yeah, absolutely. I have an anecdote about this, which kind of told me a lot about the way that developers approach things. It's kind of a nice story because I think there's a lot of good intention. There are obviously people who don't care about accessibility enough to learn about it. It's kind of written off. Like CSS, it's written off as one of these things where it's so difficult, but it's only difficult because you haven't learned it.

I've spent ages, like more than a decade, writing CSS and I still find aspects of it difficult. The same with JavaScript or anything like that. JavaScript, I find much harder.

Dave: Accessibility has become sort of second nature. I feel that too. It's like, "Oh, I can't use pink text on white?"

Heydon: Yeah.

Dave: Well, my life is over. Yeah, of course you can't.

Heydon: Yeah, the whole gray text on white thing is kind of funny because it's technically inaccessible, but also it just looks bad. [Laughter] Yeah. No, so the specific instance that I remember was when I was working at a consulting company in the U.K. This was one of those situations where I come in. I'm the accessibility consultant. I test everything, find out what's wrong with everything, and come up with some ideas about how to improve it, et cetera.

For my own sort of mental health, I tend to only work with clients who I know are committed to accessibility. Trying to beat people around the head with it who don't care about it, I guess I just will those companies to just fail, in general. One of the expressions I like to use is that not everything should be accessible. Some things just shouldn't exist at all. Anything that exists should be accessible. It should be inclusive of as many people as it can be, but some things should just go away.

If the company culture is so horrible, the product is going to be horrible. It's bound to be inaccessible. I just want it to die, basically. I only work with organizations who are generally trying or want to try about this stuff.

This organization was one of those organizations. They really cared about it. They really listened to me. But one of the early mistakes I found was an ARIA mistake. What it had done, it completely destroyed the whole application specifically for someone who uses a voiceover screen reader, the Mac screen reader.

This is something that I discovered. I didn't realize that that was the outcome of it, but I saw that the ARIA was misplaced, and it was just written up. It was one of those things we have to solve, put it in a ticket, put it in GRO, whatever. Then, a few weeks later, this came up again because we'd got kind of a complaint, I suppose.

It was quite politely worded, but this person wrote to the organization and said, as I explained, "This is not working for me at all. I'm a voiceover user. I cannot use your website whatsoever because I'm a voiceover user. Is there anything you can do?"

We were like, "Well, what do you actually experience? What's the problem?"

They said, "The whole page is just read out as just one piece of text. There's no structure. I can't find headings, lists, or anything like that."

I suddenly recalled this thing that I discovered. What it was, was React has this switch component that kind of wraps the roots. I don't know if the latest version of React has this but, in any case, there was this switch thing. You put all your roots inside it and it's kind of like the wrapper for the roots. It helps you switch between them, I guess.

Someone had thought, "Let's make this accessible," done a sort of cursory glance of some ARIA, and discovered role equals switch. Role equals switch turns the element that it's on into a button. This thing, which was the wrapper for the whole page, like the whole application, had been told to communicate itself to the browser.

Chris: Be a button?

Heydon: Yeah, to the browser and, therefore, to the assistive technology, to the screen reader, as a button. Yeah, the experience they're explaining then suddenly made sense, so they're encountering this thing. As soon as you tell something it's a button, it can't have structured content inside it. Everything gets flattened into just being a label.

At that point, I was being asked to kind of motivate the team because I was going to leave, as someone who was working with to try and motivate them to kind of carry the torch of accessibility after I left. I was able to come up to one of the developers and say, "Okay, no matter what else we do today, in the next three or four minutes, we're going to make this application 100% more accessible for at least one person," and we just removed role equals switch.

It's kind of funny because it then went through this very complicated verification testing process and everything. I knew damn well that removing that thing would have no adverse effect. It would only make this one person or any voiceover user's life better.

Dave: This is purely an ARIA role. You're not changing HTML. You're not changing CSS. You're not changing JavaScript.

Heydon: Exactly.

Dave: It was just an attribute.

Heydon: A lot of the problems that come with ARIA, and it's probably why it was such a big thing in WebAIM's study is that it quite often, or in most cases, changes the semantics. It changes the way things are communicated without changing the way they behave, necessarily, or there's a mismatch between the two things. In this case, it actually, in voiceover, with the voiceover running, actually kind of made it behave like a button. Clicking it wouldn't do anything, but it did treat the page's content like a label.

The cool thing was that we did that little thing and then we forgot about it. Then the next day, the person wrote in because I sneakily pushed this to master knowing that it wouldn't kind of break anything, which is a bit cheeky. I kind of jumped the queue a bit, but I just wanted to make this happen so that I could back to the developer and go, "Look what we did."

Chris: Yeah.

Heydon: They wrote back to us, and they were just really surprised at how quickly we'd turned this application into something which was total shit and they couldn't use at all into something which was actually perfectly okay, within like a day. Like they'd gone to bed and got up and, suddenly, they could use the website.

Chris: Wow! I mean I guess the moral of the story is, one ARIA role can just sink a ship.

Heydon: Exactly.

Chris: So, just be careful.

Heydon: Exactly, yeah. Yeah, it's a very powerful tool but, actually, in a lot of cases, just for efficiency sake, you want to use native elements. If you've got a div and you put role equals button on it, it will appear as a button. But then you need to make it focusable by having tab index equals zero. Then you need to actually bind keyboard events so that, when you use the keyboard, you can click it, and so on and so on.

It doesn't support the disabled attribute out of the box. You'd have to do that with ARIA too and make it not focusable whilst it's in the disabled state. It goes on and on and on. You could just use a button element and it's going to be more efficient, as well as more robust. And you get user agent styles as well.

Chris: Yeah, that's a great one. There's a reason that one is such a classic is because it's just one element and it tells such a complex story. Then it's like, well, if the story is that complex just for button versus div, imagine a whole interface.

Heydon: [Laughter] Yeah, exactly. Yeah. I do think it's really sad, the state of things, but it's this tension. One of the great things about the Web is that you don't have to do things in a specific way. You can be creative, you can be experimental, and you can kind of put your own mark on things. But in order for that to be possible, the code has to be very forgiving, doesn't it? You can mess up your CSS and most of it will still pass. You can mess up your HTML and it's not going to just not load because there's a bit which is arguably inaccessible or whatever. Unfortunately, that also means that it's kind of the Wild West as well, isn't it?

Dave: I just finally read Bruce Lawson's "The Practical Value of Semantic HTML".

Heydon: Hmm.

Chris: Ooh, that's a good one.

Dave: Where he kind of talks about, like, why did we do this? He's the HTML5 doctor.

[Laughter]

Dave: He's been doing this a while. Then he also calls it an old fart's guide to HTML or something like that.

[Laughter]

Dave: A dull, old Web fart guide. It was neat. It was just around forms. That's the most obvious cell, like, "Oh, shoot. My form now works on an Apple Watch and I did nothing." That's cool tech.

Then you get into the article element. That formats it into a reader view. You get into the header and footer that people can skip those or navigate to those, or the main element can navigate to those using their router in a screen reader. There are so many unknowns about semantic HTML.

Yeah, anyway, we should probably wrap this up. We're getting very late.

Heydon: Yes, sorry.

Dave: We'll have to Part II this.

Heydon: If I hadn't talked about the Vanilla Ice film -- [Laughter]

[Laughter]

Dave: We may have to cut that out. No, but we didn't even get to talk about the Holy Albatross, which solves layout on the Web, so we'll have to figure that out. Heydon, thank you so much for coming on the show. For people who aren't following you and giving you money, how can they do that?

Heydon: Oh, well, the "Inclusive Components" was funded by some generous people whilst it was a blog, and then I gave the book free to them. I don't actually have anything for sale at the moment. That's all kind of done.

I don't really need money. Give it to charity instead. Support a progressive campaigning organization. Support your trans brothers and sisters. Give them some money.

Dave: All right. Well, thank you very much. 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.

Chris: You know ShopTalk has a job board, right? ShopTalkShow.com/jobs, which is full of jobs about the stuff that we talk about on the show a lot, Web design and development.

There's one job on there that we want to tell you about in particular. There'll be a link to this job posting as part of this show, of course, and it's for a senior interaction designer in Chicago, Illinois, at a place called Tock. Their URL is exploretock.com, which is worth checking out just anyway because it's kind of an amazing little app that they're building. It's a restaurant management app, which I feel like all of us, even if we just go to restaurants sometimes, we can see how kind of bad that is sometimes at so many different restaurants.

Anyway, the story is, there are these guys. They opened this restaurant. Incredible. Three Michelin stars in Chicago. They have dedicated staff just dealing with reservations, and they lose some hundreds of thousands of dollars a year on cancellations, specifically.

Anyway, the guy goes on to found, with some Google guy, this company, Tock, that is blowing up and people are loving it. It's winning awards for industry innovation and stuff. It just looks fantastic. It looks like, "Oh, gosh. Thank God somebody is tackling these problems dealing with all the different stuff at restaurants," which is not only reservation management, but dealing with your tables, communicating with your customers, and all kinds of stuff like that.

They'll do a better job of describing it, but you should go check out the site just because it's interesting software anyway, but they need somebody who is an HTML, CSS, and JavaScript person because they're building in React, but I like that they mention React last. They want your HTML, CSS, and JavaScript skills; you're comfortable reviewing code and getting code to production; you care and empathize with users; you care about metrics and data; you understand business constraints, and all that type of stuff.

Of course, you do already because you listen to this show. It makes you good at those things, darn it. Check it out. Go work with them in Chicago. It looks like they have a wonderful place to work and it's a darn good job.

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

Chris: ShopTalkShow.com.