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 coders now that don’t have that and they just kind of go out and create stuff without necessarily either understanding or caring about the importance of semantics?
Eric: I guess it depends on what you mean by an advantage, because they have the advantage of not worrying about those sorts of things so they can break things faster [laughter]–
Nic: Right
Eric: –But also deploy something faster. But I think those of us who have been around awhile have the advantage of understanding the nature of the web and therefore a way that might be a little bit slower but doesn’t break things quite as often. Because the web was fundamentally designed to be accessible and to be, in a sense it was designed to be fundamentally responsible, although that’s– that might be stretching things a little bit but it was definitely, I mean, it was fundamentally designed to be accessible. I’ve said in other context but the web prioritises ubiquity over consistency and a lot of these– there have been a lot of attempts to prioritise consistency over ubiquity. Flash was one of the first major examples of that. If you had the Flash plugin, great, you got a consistent experience but if you didn’t or couldn’t have the Flash plugin you got nothing. That’s consistency over ubiquity. The web on the other hand is basically designed as, ”I don’t care if you’re a text mode browser on a feature phone, you should be able to read this content.” And a lot of the frameworks these days, and by these days I mean the last five to however many years it’s been that frameworks– especially Javascript frameworks have gotten huge, tended toward more the consistency side. Sometimes developer consistency side but still, we’ve seen websites that are literal magazine websites where if you dont have javascript for whatever reason, you get nothing. And, it makes no sense. I get it if you’re writing a video game on the web there’s going to ve Javascript and whatever code, web assembly I guess now. And it’s not going to be a complete experience, like, of course, but [laughter] that’s not what most of these frameworks are for they’re for “How can we rapidly push out content in modules” and a lot of the time I find myself looking at pages that because I happen to be on a train that went into a tunnel and half the Javascript didn’t load. I get nothing. I might sometimes if I’m particularly fortunate, get a snarky message telling me to upgrade from my ancient web browser [laughter], even though I’m on Firefox or the latest version of Safari mobile or whatever. Other times I just get a blank page. And that’s how it is, to me it’s frustrating both as a user because I wanted to read the article or see the product or whatever. But it’s also frustrating me as someone who deeply cares about doing this right because I look at that and I think, okay “this happened to me in– I don’t know, New York City on the subway because the signal’s not great down here but what happens to somebody in rural China who– or rural Ohio for that matter where the bandwidth is terrible because nobody has run fiber to the cornfields of western Ohio. And I don’t say that pejoratively, I live–
Nic: That’s what it is
Eric: –I’ve lived in rural Ohio, in fact my sister lives in a house where the only reason she has fiber is that she happens to live near the house of somebody who was very important to an ISP and needed to be able to work from home. And so the literally ran fibre to that house and then were able to branch off of that. But there, half a mile or a mile away from her house, there are houses that are just as rural and they have copper and they are lucky if they get 1MB per second download.
Nic: Yeah, we have been looking for a house to purchase near Ottawa. Capital city of Canada and you go about 20 to 25 minutes away from downtown Ottawa and you’re lucky if you can get 5MBs down. And they charge you an arm and a leg for that and they call it high speed internet access. And it’s like, yeah
Eric: Yeah.
Nic: We have, I think, as designers, developers, we have to stop thinking in terms of “Hey, it works fine on my computer with Megabyte internet access, 36 inch screen no problem”. While we are not representative of all users I don’t think.
Eric: Yeah, I’m sure you remember back in the day the ‘This page, Best Feed’ on Internet Explorer or ‘This page [crosstalk] Netscape Navigator. A lot of times our development process is This Page Best Feed on my computer [laughter]. Right?
Nic: Yes
Eric: [laughter] I Mean, that’s what a lot of us do. And another example, I was just– I recently got to experience the joys of satellite internet. And their download speed wasn’t terrible but when you’re doing satellite internet the speed of light affects your ping time for your packets. Your packet response time is bound by the speed of light. And there’s a– you’re looking at at least 500ms ping times, just to get the signal up to the satellite and back down. Nevermind the rest of the, you know, getting whatever the ping time is from the satellite station on the other end of your connection. You’d be going on and getting stuff and then coming back and processing it and then sending it back up. So you’re often talking about one, two, three second ping time, on packets. A lot of the web doesn’t work very well in that scenario. Even wikipedia was occasionally difficult. It was pretty good, so I tried to stick to Wikipedia. A lot of the Web was not great.
Nic: Has your view of accessibility changed since you’ve started thinking about that?
Eric: No, I think it’s all part and parcel of the way I’ve always looked at it. It’s the– make this as performing– make this site as performing as possible. Make everything as small as possible. Make it as semantic as possible. Don’t depend on massive frameworks for libraries if you can possibly avoid it. Squeeze everything down as far as you can. [inaudible] HTTPS to HTTP2, is it HTTP2 or HTTPS2? Whichever one it is that opens a connection and that can stuff everything down without having to have a seperate server call for every asset you try to load. Like that will help some but in satellite situations maybe not as much, I mean it will help but probably not as much as we would like to think. Because the server still has to, like, “Here’s all your stuff”, but a few seconds from now I hope you get it [laughter]. And I also wonder– I don’t really know the technical details. A little bit of me is a little bit afraid of “what happens if a packet gets dropped, where it drops half of your content and half of your Javascript, in this stream. Hopefully there are ways to– there are things in the protocol to prevent that. And you’ll probably have 16 people telling you that I have no idea what i’m talking about And I readily acknowledge that, I have no idea what I’m talking about, like, after 30 or 40 years of working with computers, you start to have this sort of intuitive sense of “Hey, what are ways this could break”.
Nic: Yeah
Eric: You’re probably like that too, I would think
Nic: Yeah, and sometimes it’s like, the more I know the less I feel like I know. And it’s just a weird thing.
Before wrapping it up for this week’s show, Eric, I would like to ask you, What do you think your greatest achievement is in terms of web accessibility.
Eric: [whistling] My greatest achievement in terms of web accessibility? Wow. That’s a big question. I can think of one of my biggest failures, but I guess we can talk about that next week. My biggest achievement? I would say, [pause] for me personally it’s the HTML tutorials that I write– that I wrote when I was still at Case Western Reserve University, so I wrote these introduction to HTML tutorials that were just, the first two were about HTML 2.0. The first one was basically HTML 2.0, the second one was mostly forms but also some other stuff that I hadn’t covered in the first one and the third one was about the differences in HTML 3.2. But it was written in what I like to think of as an engaging voice, similar to the voice which I write with today. And the end of each chapter had four based quizzes where they were multiple choice. I wasn’t about to do natural language processing. But it would be thing like, “ The HR element– The H in HR stands for”, and then there would be three possibilities. One of them is the correct one and it had these other things but that goes without access– what I was trying to do there was make the web accessible to people who wanted to put things online. And so by teaching– this is what these elements mean, you don’t get to control what things look like and if you hear examples and here’s how easy it is to put things online. That was, I think, probably my biggest contribution. Also because I wrote them in 1995 and 1996, there weren’t many other tutorials online and so they actually reached a lot of people.
Nic: Yeah, I think that’s one of the things, your teaching material has been around and had the opportunity of forming a, I would say a whole generation of developers and designers and from that perspective that’s really important.
Eric: I was glad to be– I mean, very lucky, very fortunate and very glad to be part of that first wave of teachers and educators and advocates who– I didn’t form a generation alone, there were a whole bunch of us. Molly Holzchlag, Jeffrey Zeldman and Jeff Yeen and, other people who I will be embarrassed to not have named later. But who all sort of had the same ethic and the same idea of– Oh John Ulsop, I’m sorry John [laughing] another one. Together we sort of helped the next wave, because that’s how we had learned, the very first wave, the first people on the web. Including Sir Tim, before he was Sir– were helping out, they were on mailing lists, so they would answer questions and there were Usernet groups where people with experience and expertise would answer questions and wwe would sort of figure it out. We learned from them so it was sort of incumbent on us to pass on what we had figured out and what we had learned from them to the next set of people.
Nic: Pass it forward I think is such an important concept.
Eric: Absolutely
Nic: Eric, thank you so much for joining me. We are going to wrap it for this week and we will reconvene next week.
Eric: Sounds awesome. Thank you sir.
Nic: Everyone out there, thank you for listening to hte show, I hope you enjoyed it and if you d, please do tell your friends about it.
You can get the transcript for this, and all other shows at https://a11yrules.com and a quick reminder, you can get yourselves some neat accessibility branded swag at https://a11y.store. Catch you next time!