This week, I had the luck and great pleasure to talk with Jeffrey Zeldman, who probably needs no introduction but who refers to himself as a “web designer who’s been interested in inclusive design for a very long time.
Transcript
Nic: Welcome to the Accessibility Rules podcast. You’re listening to episode 21. This episode has been sponsored by patrons like you. I really do appreciate your support. I’m Nic Steenhout, and I talk with people involved in one way or another with web accessibility. This week I’m speaking with Jeffrey Zeldman.
Basically having conversations with people that have … Either live and breath accessibility or have a finger in the pie. And thank you for agreeing to come on the show.
Jeffrey: Yeah. It’s my pleasure. I’m really thrilled that you asked me. I’m definitely not an accessibility expert by any stretch of the imagination. What I am is a web designer who’s always, always … Well not … Once I figured out what I was doing about two or three years in, I thought, “Oh this is great because it’s for everyone.” So, I’ve always been interested in inclusive design and I’ve always felt that inclusive design could be beautiful and could be a rich experience, and all the stuff that we know to be true. And yet, I feel like sometimes like I’ve been … Progress is funny. It moves in one direction and then it goes in the opposite direction for a while and you’re … I feel like … I just read today … Who is it that just spend a billion dollars on their redesign?
It’ not Etsy. Hold on one second. I’m sorry. I’m going to check this. They spent a billion dollars on their redesign, and it only works in Chrome. Airbnb. I’m sorry. Sorry, no they didn’t spend a billion dollars on their redesign. Okay, let me correct all my errors. Airbnb, made a billion dollars in revenue last quarter. Last quarter. Not last year, last quarter, but their website only works in Chrome because they can’t afford to … I mean I’m like … And you might say, “Well that’s not an accessibility issue per se”, but it is. It’s the same thinking. It’s the non-inclusive, let’s take some random segment of the population. Rich people with modern computers and a modern browser, and let’s say, “Yeah, everybody has to do that. And if they don’t do that, then we don’t care what happens to them.”
Nic: Well it is a bit of an accessibility issue isn’t it? Because if you’re on Mac and you’re using Voiceover, the only browser that truly behaves well with Voiceover is Safari. So you don’t have access to Chrome.
Jeffrey: Right. There you go.
Nic: Yeah. Hey, Jeffrey, we’re talking about web accessibility this morning. There’s about two billion different definitions of the word. How would you define it?
Jeffrey: Right. I would go back to web standards principles like progressive enhancement which say, the web is genius because it allows everyone access to content and to interactivity. And I would say that an accessible site is one that allows anyone, regardless of native physical ability, regardless of temporary physical ability, regardless of device used, or browser, or phone used, to access content. Doesn’t mean they have an identical experience. Obviously someone who can’t hear isn’t going to hear, someone who can’t see isn’t going to see. Someone using a really old browser may have a simplified layout. But everyone can get to the content, everyone can do what the website promises to let them do. Because basically we’ve had interactivity since HTML1. Right?
You could always check a box, and you could always make something happen by clicking a link or by doing something that triggered an activity on the server. So I think now the struggle, for me, not in what I do because I know how to make accessible standards compliant websites. We have a person on our team, Robert Jolly, who makes sure everything is compliant. And we design with that in mind from the get go so we’re not retrofitting anything. Which again, people complain that it’s too expensive because they’re trying to retrofit and that’s like saying, “It’s too hard to make a toaster because I just built this jet plane, and how am I going to turn it into a toaster?” And you’re like, “Yeah.” But if you start with the toaster, it’s pretty easy to make a toaster. So I think what it means to me is just not wanting to exclude anyone. Which also means not wanting to exclude any device.
To the absolute highest extent of that is feasible. And you’re making something that is wonderful for everyone also. Because I don’t think like a crummy experience. Like giving text descriptions that are really bare bones, on something that’s really rich for sighted people, probably not the way to go. Probably spend some time writing good captions. Writing good alt text because you spent time on the illustration. But I feel like we’re back to square one in some strange way because there’s so many people, Airbnb being just one example, there’s a million examples where they’re like, “We’re just doing this for Google,” or “We’re just do … You have to have JavaScript.” And they … And it’s not that most people’s browsers don’t support JavaScript, of course they do. And it’s not that most people turn off JavaScript. They mostly don’t. But once you say, “You need to have this thing or it doesn’t work at all,” you’re excluding people.
So I come at a from a … Well I come at it from two points of view. One is as a craftsperson. I’m trying to craft the best site I can, so I want it to work for everyone. Just out of professional pride. I would feel bad and stupid if it just didn’t work. And then, from a humanitarian point of view because I think to tell someone, “No you’re not welcome here …” I mean that’s a whites only fountain we had in America in the 19 … Well until the 1960s. And some people would like to go back to that time. But I would not. The idea that you tell one group of people, “Yeah, you know we don’t really care about you,” or “You’re not welcome here,” that’s wrong. That’s wrong. And I don’t know. I feel like I’ve been fighting this fight for a long time and I get tired.
Nic: I know totally. I’ve been around doing this for a very long time and it gets tiring to say the same thing over and over.
Jeffrey: Yes.
Nic: Yeah. So you’ve been a supporter and advocate for accessibility for a long time now. You’re doing a lot of work through your A List Apart and your An Event Apart. You mentioned and skirted around a little bit just now, but if I were to get you to give us a pulse … You know how is our industry doing with regards to accessibility? What would you say? Are we doing good, bad, awful, excellent? What’s going on?
Jeffrey: I can’t really speak to the whole industry because I … Although I’ve been doing this since 1995, I’m not in the mainstream. I’ve never been in the mainstream. Right? So my friends and I were doing web standards to do sites. Everyone else was using cable layouts, and then we were doing web standards. Everyone else was doing Flash, and you know I just kept saying, “Eh. I know my site’s uglier. I know my client would like to be prettier. And I know it could be much prettier with Flash, but I can’t do it. I’m sorry. I just can’t do it.” So I won’t take that job. And I won’t … I always sort of put those principles first. And I don’t want to sound like a pious person or like I’m not fun. It’s not … There’s no piety, it’s not a religious thing. It’s just I can’t even imagine making something that you know doesn’t work for people. It just doesn’t seem sensible or nice.
So I do what I do, and at my studio, Studio.Zeldman, we do what we do. And I know there are plenty of other good studios. A lot of small studios that really care about this too. There are lots of people in our field that care about this. There are people at some product companies that care about it. And from that point of view I think there’s a lot more knowledge. There are a lot more books on accessibility out there than there used to be. But at the same time it still feels to me like a minority point of view. It still feels like the industry keeps churning out people from code camps, and boot camps who know how to code which is great, but don’t have a lot of background in the whole, “Why are we doing this,” and “How did this get to be where it is.” And who aren’t being taught because it’s not considered a job critical skill.
You see, “We’re a leading edge product team. We’re looking for a super hot code who’s a full stack developer, who knows these 17 frameworks, and these 82 languages.” And I never see, accessible standards compliant, progressive enhancement. I never see those words in the description. So there’s a lot of … I’m sure there’s a lot of people listening to your podcast who believe in this, and there’s a lot of developers out there, and front end developers and designers who believe in this. But the industry as a whole is still kind of as tone deaf about it as ever I feel and it makes me frustrated. What do you think?
Nic: Yeah. I’m thinking that we’re going backwards in many ways. When I accessibility audits, one of the things that I encounter quite often is a lot of basic semantic issues and it’s almost like developers nowadays have forgotten that HTML and CSS are actually a thing in their structure, and there’s a way to write it that actually imparts meaning. And that seems to be lacking-
Jeffrey: Well they’re grabbing frameworks. Now I get … A lot of times people say, “Oh he hates bootstrapping.” That’s not really true, and that’s not it. And I understand why something like bootstrap exists, and doing multi-column layout, especially before CSS grid, very complicated, very hard. And making it work in all browsers, very complicated, very hard. So the idea that you should be able to reach for something off the shelf, not have to reinvent the wheel, right? Someone took the trouble to code this, so you can just use it. That’s really cool. Mark Otto. Good person. Came up with bootstrap. All these frameworks come from a good place of helping people get stuff prototyped faster, get stuff built faster, and I think for prototyping with folks who are able bodied to temporarily able bodied, that’s fine.
But once you have to actually make the product I think it’s really important to code it in a way that starts with basic semantics. There are people who start with … Like my friend Jeremy Keith at Clearleft. When he starts a project, he doesn’t think, “What does this look like?” He thinks, “What are the semantics here.” And that’s where he starts. And that’s a great place. That’s an amazing place to start. But that’s all too rare. It’s usually, “What things that my competitors do, do I want to do,” and “Who has built the tools that allow me to do that quickly because I have to make five other things today?” And I don’t blame developers for grabbing tools when they’re under a lot of pressure to make stuff, and make stuff, and make stuff, and make stuff, and you’re being paid based on how productive you are not how thoughtful you are.
So in that sense … And it’s weird too because if you think about it, a lot of these products … Like I remember maybe five or six years ago, before Twitter was as huge as it is now. But it was already exploding. It was during the Arab spring. It was after the Arab spring. I was visiting San Francisco. A friend of mine worked at Twitter and said, “Come to our Christmas party.” So I went and there were like 300 developers there. And I was going, “I don’t understand. This is an SMS …” I mean if you had five or even ten I could maybe see that. And I know I’m being naïve, but I just kept thinking one person to do the basic functioning. Maybe another for like, specific platform issues. You know, I could see some backend coders, but I didn’t understand. There were so many front end coders and so many front end designers that were working there.
And I was like, “So what do you do?” Like, “Well I work on this dropdown that we considered implementing but decided not to. I spent five years on that,” or whatever. And I’m like … Do you know what I mean? I’m like, so many people just working on stuff that never even sees the light of day and I’m just going, “Is that really …” Again, I’m probably just naïve about product development. But to me it’s like, “So maybe instead of rushing and having a million people moving quickly, maybe it would make more sense to have a smaller team being thoughtful.”
Nic: Yeah. Yeah. Say, if we were to put aside the whole open web standard thing for a minute, if I talk with a typical web designer, who may or may not be aware of accessibility, what do you think is the best approach to get them to start paying attention to accessibility? How can we best turn these people that have very limited or no knowledge of accessibility into advocates and champions?
Jeffrey: Well perversely, one of the things that really helped us sell web standards and accessibility was Google. In the early days of Google, if you told a client a blind person can’t use your website, they were like, “Well I sell TVs. I don’t really care. Blind people don’t buy TVs.” Doesn’t mean their wrong, but it doesn’t … They can tell themselves that. But if you said, “Google, the biggest blind user on Earth, can’t find your content.” Then all of a sudden you had a story to tell because it was affecting their business. If you told them, “5% of the people that you’re trying to reach will never be able to access your content,” or 10%, or “We don’t know how many.” Right? “We don’t know how many people don’t even bother trying.” That didn’t seem to bother them. But if we said … It’s weird because it’s the same thing at one remove.
If you tell them, “Yeah you’re losing people.” “We don’t care about those people.” “Oh, but people can’t find you on the search engine.” “Oh well we care about people.” I don’t know why, but if it was … They new that SEO was a big deal. They knew that search engine findability was a big deal. And we said, “If you’re most important words are in your H1 headline, and you’re next most important set of words are in your H2 headline. And your lists are lists, and your paragraphs are paragraphs, then Google can find you and the other search engines can find your content. And it’s well written content.” Let’s make that clear. “And it’s well written content.” “But if you have well written content, and you put in a bunch of spans and divs, with a layout controlled by JavaScript, it’s going to be much harder for anyone to find your content.”
You tell them that, and then they care about that. So I think in a perverse way, sometimes it’s easier to get management to care than developers. If you tell management, “Yeah you’re losing SEO, and please pay this $25,000 a day consultant to spend three days working with you on a plan to use basic HTML.” “Well now that we spent this $75,000, we understand that we got to use basic HTML structured semantically.” Then you go back to the developer, and the developer complains. “Wow, I’m going to have to rework everything.” And again, this is why this thing I keep coming back to, which is if you build it the right way to begin with, it’s very simple. Also I think another thing that’s helping right now is the adoption of pattern libraries in our industry.
So it used to be, “I’m going to ship you these templates, and then we’ll install them in this expensive backend system.” And of course that often still happens, but more and more with our clients we’re saying, “Okay. We’re starting with …” Of course we’re designing pages as quickly as possible because pages are part of the system. But we think like system designers and we say, “What are the seven most important interactions people are doing here? And what do they look like? What do they feel like? How should they work?” And we sketch them really roughly and then prototype them really roughly.
And what happens is we’re not selling pictures of what the web should look like. We’re not selling paintings. We’re not doing like beautiful comps right away. We’re giving them really crude sketches and saying, “Here’s the sketch.” And it actually gets the client, again the manager, very excited because they’re like, “Yeah yeah yeah. No, you know what? That is how I sell the product and actually, here’s a potential point of failure that we haven’t even thought of, and maybe here’s a chance, a place to give someone another option.” And go, “Yeah. What would that look like?” So we’re very collaborative. We work at this level of sketches, low fidelity ugly sketches for as long as possible before we move into the very pretty comps.
Because once you’re in pretty comps, you’ve put a lot of time into making it pretty so you’re resistant to change. The client either doesn’t like it because your idea of pretty and theirs don’t match. Or if they’re polite, they hesitate to make comments because, “Oh they put so much work into it. I don’t really want to change anything, but I really don’t … I don’t like that yellow. But maybe that’s just me.” It all gets into a lot of nonsense that’s not the most important thing. So keeping it at this low fidelity level, and then when you deliver the high fidelity you deliver it as components so that it’s like we’re not just making this one time deal where there’s three thumbnails which become two responsively, or one depending on the size of the view port.
We’re saying, “There’s going to be lots of times where you’re going to need thumbnails with descriptive text and a headline. You’re going to need that over and over again.” And of course, when I’m making that element, it’s all very semantic. There’s an image, and there’s a figure, and a caption. And there’s a paragraph, and there’s a headline. And all of that stuff is very semantic and you keep combining those things, you combine those units into pages. You combine those modules into pages. And what the page looks like matters, but it’s going to change depending on the device, and so you’ve got the client buying into this universe where you’re not just designing these flat pages that are being designed on these imaginary, 1024 by 768 desktops that everyone has. Instead it’s all different, and the client knows that.
And because you’re focusing on interactions, you’re focusing on moments of connection with the customer. “And what happens next after that moment? What are the two options that the customer has? And do we want to subtly help them make the right choice?” And because you’re focused on all that, I think, I guess the last thing is the torture test theory. So pattern libraries help too. The third thing that I think helps … So search engines help. If we make it semantic and accessible … Google’s the biggest blind user on Earth so that will help. The second that helps is focusing on interactions, the actual touchpoints with the customer, and using a pattern library as a deliverable because the elements of that pattern library kind of have to be semantic. Or they don’t have to be, but they’re better if they are, and deliver that as a matter of course. And the third thing. The third thing. What was I saying the third-
Nic: Torture test.
Jeffrey: Torture test. Thank you. So it’s the … UX people love to tell stories about how … So there was a tennis racket and …” I’m not remembering the names of the manufacturer, but it doesn’t matter. This is just a teaching story. So the tennis racket was hard to handle for someone who had partial hand paralysis. So they realized that the grip could be made better, and they made the grip better. And so they made it for the person who had this disability and then they found that it was actually easier swing for everyone who used it. Or there was a good grip appliances where there were people who had arthritis. Older people whose arthritis made it hard for them to use a can opener. So they studied ways to make it easier to have more leverage with less strength, and they made it so that these products worked better for people who had arthritis. And guess what? It worked better for everyone.
Or they make the pill bottle that works better for people with arthritis, and guess what? It works better for everyone. So the torture test. The idea is, if you make something for people on the extremes of the bell curve, and you make sure that you satisfy those customers. You test on those customers. You look at their problems not as edge cases you don’t need to think about, but as the problem you actually need to solve. Look at the person with arthritis as the person you need to solve for if you’re making a bottle cap. Not as, “Oh well. We don’t care about them. This is for able bodied Aspirin users.” No. It’s Aspirin bottle. Solve for the person with arthritis, and then, lo and behold, it works better for everyone. And that is the theory that we use to sell accessibility.
That if we can solve this problem so that if a person with limited vision can use this form, then guess what? It’s actually going to be more usable for everyone. Derek Featherstone … Do you know Derek Featherstone?
Nic: Yeah yeah. I’ve worked with Derek.
Jeffrey: Okay. He’s a fantastic accessibility person. And he does this draw test where you squint through a little hole in your hand and try to look at a form, a typical web form. And you could completely comply with WCAG2 in principle, and a test. If you ran it through a software accessibility test it would say, “Oh yes. This form is …” Because you labeled all the parts correctly and there’s area roles, and everything, everything works. You’ve done everything you’re supposed to do with the code so it’s accessible. Accept it’s not for the person who has a limited field of vision because contextually it’s bad design. The words are too far apart from the things they pertain to.
So if you fix that, and move the words closer to the objects they pertain to because you’re thinking about the user with limited vision, lo and behold it’s easier for a person to scan no matter how good their vision. Anyone with vision of any level can scan it more quickly. Even someone who can see the full page at once can scan it more quickly because like things are grouped together visually, and that’s easier for the brain to understand. Which also gets us into the conceptual sides of accessibility which are little talked about and really hard to deal with. Right? What do you do with … A simple example is you don’t always know when you’re reading a foreign language that the writer intended to be sarcastic, or was referring to … And you know, I’m definitely not saying that if you’re publishing an article by a famous satirist that they shouldn’t write. They should be banned from writing.
But I’m talking about microcopy. Right? Talking about the guide copy on a website which sometimes we want to make the website feel friendly, so we encourage a sort of laxity in the content. It can actually have an off putting effect on people who don’t understand the way it’s intended, or who actually their feelings are hurt by this. It’s another form of inclusive design. But my friend Eric Meyer talks about this thing that’s been going on at WordPress forever where … I forget what specific failure triggers this, but someone thought it would be cute to have an error message that said, “Cheating eh,” instead of, “Sorry that action didn’t work because you did A and you can only do B in this form.” Or whatever. You could have had a straightforward error message. It makes sense. WordPress is fun, it’s cool. Everybody using it. Everybody’s … It’s a party. Everybody’s happy. It’s opensource. Yay. Hooray.
So someone wrote this loose error message. Anyway this thing’s been there for eight years. And they’ve had multiple discussion threads about it, and they’ve even done regionally … They’ve never fixed it. They’ve never fixed it. But they’ve done geographic … So it’s like “Cheatin’ uh,” in England, and “Cheating eh? What,” in England. And I mean, I’m doing really stupid examples, but they actually idiomized the … They created idiomatic speech depending on the geographic address and the person who’s accessing it, but they still do this insulting thing. And it happens all the time. And Eric cites the example of someone who said, “I love WordPress. I’ve used WordPress for ten years, but I’m never using WordPress again because everyday it says, ‘Cheating eh,’ to my client who gets this error message every day. It’s never been fixed, and my clients not cheating and they don’t know whether I did something wrong, I’m making them cheat. They don’t know what it is.”
So this isn’t exactly accessibility, but it’s a related thing. You have to think about … It’s inclusive. It’s the same in a way just thinking about, “Are we taking people’s needs for granted? Are we assuming that everyone who uses the web uses it the way we do, thinks the way we do, uses language the way we do?” And I think when you’re an interaction designer, when you’re a front end developer, it’s really important to take those extra minutes and remember most of us have it pretty luxurious. I’ve got the latest browser. I’ve got every browser. I’ve got a big screen, I’ve got a very fast connection. Everywhere I go I’ve got a fast connection because it’s my job and I pay for it, or my employer pays for it. But in the real world, lots of people don’t have that opportunity. So does it still work for them? I think speed is part of accessibility. Performance is part of accessibility.
Nic: We’ve been looking for a new house out in the country and obviously one of the concerns we have is to have high speed internet, and we’ve said that to our real estate agent not really thinking that we needed to define the parameters around high speed internet. Because for her, high speed internet is 5 Mb/s, and well yeah it’s faster than dial up, but it’s just not going to work for us web professionals. So when you start thinking about these issues, you realize that there’s a lot of people in the web development, web design context that, “Yeah it works,” but for real people, Joe Q Public out there, we just don’t have the same kind of access. And when I say access I’m not even talking about accessibility and disability related. So, yeah it’s important to consider all these things.
Jeffrey: If you’re a web professional and you do a lot of business travel for speaking, or conference going or to meet with clients, hotels often give you … Although that’s getting better. But at least it used to be you’d go to a hotel and it would be terrible. The access would be terrible. And you’d go like, “Wow. Google’s so slow.” And then you’d go, “Well what’s our site like? Oh my god.” Right? Right. In the earliest days when our friend Ethan Marcotte invented responsive web design, some of the first people who jumped on it were really brilliant creative professionals and nobody said, “By the way, let’s think about bandwidth,” because that’s not … I mean when you’re first diving into something you experiment.
So some of the first really impressive responsive websites had these gigantic background images, full screen backgrounds, and everything else. And that had nothing to do with responsive design. That wasn’t what Ethan was advocating. That just had to do with, that’s what occurred to the first people who made these sites. And they were beautiful, but they were problematic if you weren’t in this little charmed circle of web professionals with high speed equipment, and high speed connections. So and I think … I don’t know. I have such mixed feelings about Google these days. On the one hand they’ve been terrific advocates for performance, and making sure that everything works for everyone, and they’re the ones who’ve been saying in their webmaster tools forever, “Use correct semantics if you want good search engine placement.”
So all that stuff I love. That’s great. They’re about delivering results to customers and every second, every nanosecond matters to them. So that’s fantastic. But I worry because they’ve got this amp. This sort of … And it’s like … Yeah … I mean, yes performance really matters, but the way to ensure it is not to say, “So use our proprietary version of HTML, and let us serve it for you and then everything will be fine and dandy.” So kind of like, then you’re becoming Facebook aren’t you? You’re taking my content, and telling me to format it in your HTML on your site. I’m not comfortable. But in general, I think Google has over the years been a really good force for accessibility party by design, and partly just because if you wanted search results, then you had to use semantics.
Nic: Yeah. I’ll conclude this episode here. Thank you all for listening, and stay tuned for the rest of my conversation with Jeffrey. It will be available next week. Before I go, I want to thank my patrons once again. And remember that if you need a hand ensuring your site’s accessibility, I’m available. Contact me on my website at INCL.ca.