Show notes
Eric talks about accessibility, of course, and semantics, and frameworks, and more! The web prioritises ubiquity over consistency and a lot of these-- there have been a lot of attempts to prioritise consistency over ubiquity. Thanks to Twilio for sponsoring the transcript for this episode. Make sure you have a look at: Their blog: https://www.twilio.com/blog Their channel on Youtube: https://www.youtube.com/twilio Diversity event tickets: https://go.twilio.com/margaret/ Transcript Nic: Welcome to the A11y Rules Podcast. This is episode 51. I’m Nic Steenhout and I talk with people involved in one way or another, with web accessibility. If you are interested in accessibility, hey, this show’s for you. To get today’s show notes or transcript, head out to https://a11yrules.com. Thanks to Twilio for sponsoring the transcript for this episode. Twilio, connect the world with the leading platform for voice, SMS and video at Twilio.com. Hello everyone, so this week I am speaking with Eric Meyer. Eric, thanks for joining me for this conversation around web accessibility. Eric: Thanks for having me. Nic: I like to let guests introduce themselves. So, in a brief introduction, who is Eric Meyer? Eric: I’m a-- I mean, this is a difficult question to answer sometimes. When I meet people out in the world and they say “What do you do?”, I always struggle for an answer, but, I guess the best answer is that I’m a technical Author and explainer. I’ve written a number of books about CSS, co-founded web design and development, sort of, education conference with Jeffrey Zeldman. When I say education conference, I mean that we-- our goal is to have people come away from every talk with something that they’ve learned and something they can put to use-- Nic: Right Eric: --Doesn’t necessarily mean exactly higher ed, although we have higher ed people come. I have a family, live in Cleveland, Ohio. I really like it here, even when it is hot and humid. And, I don’t know, I guess I’m someone who has been working on the web for a really long time, still finds it fascinating, compelling, something worth advancing. Even with all the downsides And someone who hopes I can continue contributing to that conversation. Nic: Well you certainly have contributed your fair share over the years and I want to thank you for that, and I’m sure that pretty much all my listeners will be very thankful for all your work. Eric: Well, I mean, I hope it was useful. That was really always the goal was to either-- well it was to be useful in one way or the other. Either to help people understand something they didn’t understand before or give them a thing that is useful to them. And, you know, I’ve had my stumbles along the way, we might talk about that later, but, yeah. Yeah. Nic: To get warmed up a little bit, tell us something that most people would not know about you. Eric: Well, Something that most people would not know about me? My first job was working at a McDonalds in, just outside of Mansfield, Ohio. Which is where I grew-- I grew up in that area. I grew up actually in and just south of Lexington, Ohio which is south of Mansfield, Ohio. Most people will not have heard of any of those but I-- when I was hired, for my first seven months, I worked the fry station because it was a busy enough, and demanding enough McDonalds that you started out on the fry station and then if you proved that you were capable of working and learning you might get promoted to the grill. And then if you were really good, you might get promoted to cashier. And if you were really, really good you might get promoted to working the drive-through. I never made the drive-through, I did-- by the time I was done with my two and a half years of work there, I did manage to land some time on the cash register. But-- Nic: We do have something in common, that we have both worked in food service before. And although I didn’t actually work at McDonald's I took the option of going for the apprenticeship and became a chef and all that-- Eric: Oh wow. Nic: -- good stuff, but I have a few friends that were with me in cooking school that said that McDonald's didn’t really teach them to cook but it taught them organization, it taught them being able to think on their feet and all these things. Do you think you have transportable skills that you learned from McDonald's that you’re still using today? Eric: I think what I took away most from McDonald's, I mean, not to contradict your friends, I agree that learning to think on your feet and also being able to worth within a system without switching your brain off, are things I learned. But I think what I took away from it most was an appreciation for what people in the service industry do and, this-- the many constraints that they work under often. And that also, that gives me a perspective on, sometimes people talk about web design and web development as a service industry and I always sort of itch at that a little because I think to myself, no, I’ve worked in service, this is not that. We do provide services, but to conflate that with what is generally thought of as the service industry I think sometimes does a disservice because we have a lot-- generally, have a lot more flexibility. I mean, I’m sure everyone's had a client where they tell you exactly what to do and if you try to be creative they snarl at you about who's paying your [laughter] salary and then you just do it, right. And then you try to get away from that client as quickly as possible. But most of the time it’s, you know, at McDonald's management was not interested in me asking, “when we say we are making a hamburger, what problem are we really trying to solve?” [laughter]. There’s no room for that. There’s just, “We need six hamburgers right now”, or 12 or 24 or whatever, it’s not like, I worked in a McDonald's where sometimes it was busy enough that it was not unusual to hear a call for 96 hamburgers on the grill. Nic: Ouch Eric: Yeah, because four tour buses would pull up, and it would just be like, “We’ve got four hamburgers ready to go. Put 96 down”. And we would, boom, boom, boom, boom, boom, right, right. And everyone scrambles. You start out slow and you learn to be fast, and, anyway. Nic: I guess it’s better busy than bored. Eric: Yeah, and the other thing I think I took away from it was teamwork. Nic: Yeah Eric: The ability to work in a team, even when some members of the team might be less than pleased with you Right? [laughter]. Nic: Yeah Eric: I remember when I was early on the grill, you know, when I got moved to the grill and I was sort of early in that process. I was slow. Right, I mean, I didn’t really know where everything was. I had this thing where it was like, you have to put the ketchup and the mustard exactly in the middle of the bun or else it’s not right. And, yeah, you learn quickly how to do that faster and maybe-- you know, communicate with other members of the team. If the guys who is literally on the grill, cooking the 96 hamburger patties is getting close to them being done and he needs dressed buns to put them on, he’s going to let you know and you communicate back if you’re ready or not. So-- Nic: Yeah, yeah, yeah Eric: That whole teamwork thing definitely came out of there, and I’m sure you learn that as a chef as well. Nic: Yeah, teamwork. Absolutely. Well, the main point of this general conversation today is talking about web accessibility and for some reason every time I talk to somebody else for the podcast I hear a variation on the definition. I’d love to hear- How would you define web accessibility, Eric? Eric: I define it as getting the most information available to the most number of people, the greatest number of people. So, if that means, making it so that screen readers are happier with your content so that people who use screen readers can get all of your content. That's web accessibility. If it means not relying on Javascript as much as possible so that as much of what you’re trying to get to people comes through. Even if they don’t have Javascript, that's accessibility. Keeping your bandwidth consumption low so that people in low bandwidth situations, that’s accessibility. The web was fundamentally designed to be accessible, in as many contexts as possible. So, that how I design web accessibility, it’s just, can the person who is trying to get your stuff, get it? If they can, it's accessible and if they can’t then it's not. Nic: Yeah. Bottom line, that’s what it is about. It’s about people being able to access the content you’re putting out. So, you’re not doing accessibility day in, day out like some of us do, you know, we are accessibility wonks and that’s what we do. What would you say your role is in the greater scheme of web accessibility? Eric: I think it’s advocating for the principles that I just talked about. I just recently, unexpectedly found myself doing a three day web development training class, and so I thought it was going to be three days but each day would be 30 minutes and I got there and they said, “So, three days, right?” and I was like, “Yeah, three days of talks”, and they said, “Yeah, three full days” and I said, “Oh, okay” [laughter]. This was a volunteer situation so I didn’t have to renegotiate what I-- there was no rate. Nic: Right, right Eric: Like there was no contract to renegotiate. And I was happy to do it, but I was-- what I stressed from the outset was, the web is designed to be- I didn’t use the words accessible but designed to be as robust as possible and if you’re going to do this-- because I was talking to who were effectively high school vocational students. So if you’re going to do this for a career, this is what you need to know [laughter]. Along with that, what people might think of as the more traditional accessibility bits, if I-- in fact I was acting with a website just yesterday that’s basically completely unusable on my iPhone SE because content is overlapping. And I’m trying to complete a form to schedule an appointment and there's this red banner across the top telling me that this is where I should schedule my appointment and I can’t because that banner is covering up the stuff and I can’t , I kept trying to pull the page down so that I could let go and tap before it snapped back up on me Nic: [laughter] Eric: Right? So basically I’m going to call them later today and I’m going to say, “Oh, by the way, your web form, your online scheduling thing that I tried to use because that’s what you recommend, completely unusable and you need to fix it”. Nic: Yeah Eric: So, those sorts of things. And just in general if I see an online-- in the general online conversation somebody says “bah accessibility” or widespread access those are edge cases to point out how they’re not. Nic: Yeah Eric: I don’t see a lot of that I have to say, but they might-- that’s probably just a function of where-- who I’ve followed and who follows me and the sort of places I look. I’m not-- I have to admit, I’m not out there looking for opinions to contradict. I’m not searching for people seeing accessibility as pointless in order to correct them. It’s just if it comes in front of me I’ll speak up Nic: Well there's enough cats to heard as it is without actually going looking for trouble Eric: [laughing] Yeah Nic: How did you become aware of the importance of accessibility? Because it’s probably not something that as you started building the web, building your approach to CSS and all that. It’s probably not something that immediately jumped out at you. Eric: Actually to some degree I think it did immediately jump out at me. I started out on the web when I was working for Case Western Reserve University, which is a private university in Cleveland. It’s actually the University I graduated from and then I immediately went to work for them in an attempt to earn back all the tuition money I had given them [laughter]. Which worked. I had to hang around longer than four years to make that happen, but it worked. It was 1993 when my coworker and longtime friend, Jim Nauer showed me a early beta of Mosaic, and I got really psyched by it and started, like, “how do I do this?” and he said, “well, here’s a link to HTML 2.0 specification. That's what we’ve got.” I said, “great!” [laughter] So anyway, I quickly got really into it, became the first dedicated campus webmaster, back when we called ourselves that. Nic: Yeah, I remember those days. Eric: Right? And at the time there was no presentational control from the author's point of view. So when I started out, literally the closest we got to presentational control was H1’s were usually big and B was usually bold-- or strong, sorry. Nic: B at the time, I don’t think we had strong at the time. Eric: Oh yeah you might be right. Well whatever you write, that’s usually bold and the pre-formatted usually looked like-- we said at the time it looked like a TTY. I guess sometimes people still say that. So there wasn’t that sense of control and it was more-- all you could was structure stuff. You could structure things semantically, or you could try to subvert the semantic nature of the mark up in order to try to create a presentational effect, but, browsers didn’t have consistent presentational effects and in fact mosaic at the time had these preferences where, as the user, you could say what H1’s looked like and what H2’s looked like, and what H3’s looked like. You could set the font face, size and colour. So most people, once they found that preference, made H1’s tiny and H6’s huge. They inverted the size. And you would go surfing around the web and be like, “oh look at the tiny H1, that’s hilarious haha”. Because there wasn’t a lot to do in those days, and then you would quickly revert it because that was terrible. So there was that aspect of things where everything was semantic, there wasn’t really an option of this is what I want this to look like and therefore it will, the only thing you could do was just make a big image and load that. And at the time with the internet speeds we had, like, 640 by 480 gif because we didn't’ even have jpeg support at that point, would take a minute or two to load and some people did that because there weren't many websites. The other thing was working on a college campus, and especially at one like Case where they have a strong Sciences component. The engineering department, the math department, the computer science department and so on, physics department. There were these professors who knew more about computers than I did. Probably had their own IRIX workstation, and they had some bespoke compiled version of some browser I’ve never heard of and if I put up a webpage and they couldn’t read it, i would hear about it. There was a guy in the math department particularly, I’m not going to name names but, there was a professor in the math department who had this-- I don’t even remember what the browser was anymore but it was like, you know, it wasn’t even Viola or Cello or one of the obscure ones that people know about. I don’t think-- whatever he was running, I don’t think it has a Wikipedia article. And I would hear from him, because we would put up the course catalogue. It was one of our first big projects and there was some weirdness to it. He could read it, but it looked a little weird. And I would hear about it. And that really sort of reinforced the-- it’s a big wide campus, with a lot of different user agents, a lot of different people coming and they would want to be able to get this information and that’s what I’m here for. So that was sort of, hammered into me early, just by experience. Nic: Do you think that those of us that are so ancient that we remember HTML 2, that we really were forced to focus on the semantics of the page and then understand these things like page structures and all that. Do you think we have an advantage over newbie code…
Full show notes at the publisher