Billy Gregory, who works with The Paciello Group as Director of Training, talks to us about accessibility, and, among other things, tells us that we shouldn’t worry about accessibility laws or regulations. Instead, we should worry about whether or not people can stay in touch and do all the same things that we can do.
Transcript
Nic: Welcome to the accessibility rules podcast. You’re listening to episode 17.
This episode has been sponsored by patrons like you, and I really appreciate your support.
I’m Nic Steenhout, and I talk with people involved one way or another with web accessibility. This week, I’m speaking with Billy Gregory. Hi, Billy.
Billy: Hey, Nic. How’s it going?
Nic: Pretty good. Thanks for joining me for this conversation about web accessibility. I like to let guests introduce themselves, so in a brief elevator pitch style answer, who’s Billy?
Billy: Wow, okay. I guess I wear a few hats. I’ve been known as the director of training for the Paciello Group. I am the co-organizer of A level YTO, which is a meetup group based out of Toronto. We do camps, meetups, and conferences. And I’ve also been called a lumberjack in my day. So yeah, pick a hat and I can wear that one.
Nic: What’s the lumberjack thing?
Billy: My buddy Karl Groves and I, we had a – well, we still have – a web series called The Viking and the Lumberjack. We try to take accessibility and put a lighter tone around it, dress it up a little bit, and make it more, for lack of a better word, I guess accessible for people. We try to make it fun and engaging, and show people that our community does have a sense of humour, and we’re not just this angry mob with pitchforks that come after you whenever you mess up something online.
Nic: Right, yeah. That’s good. We’re talking about web accessibility, and there’s fifteen billion different definitions of web accessibility. How do you define it?
Billy: I love telling this story whenever I do my training. I think I define it really as just being able to talk to my friends. Being able to … I guess, being able to stay in contact. And giving people the same opportunities that everyone else has. Levelling the playing field, I guess is the best term. We have this weird definition of what is accessible, and what it means to different people.
My buddy Johnny Taylor, abled access on Twitter, summed it up the best once. We were chatting at a camp a few years ago, and everyone’s like “What’s the definition of done? When do we know that something’s accessible?” All this. And we were all trying to give these long-winded answers to make ourselves sound smarter than the next person, and Johnny just kind of looked at us and laughed, and then we asked him what he thought the definition of it was. He just looked up, he said, “I know something’s accessible when I can use it.” And to me, that was an eye-opener. I realized that it’s just really about making everything usable to everyone.
So for me, that’s my definition. I don’t worry about laws, I don’t worry about regulations, I just worry about whether or not my friends can stay in touch with me and do all the same things that I can do.
Nic: You think accessibility is just for people with disabilities?
Billy: No. Not at all. That’s why I was saying it was about levelling the playing field. It’s really for everyone, and we’ve talked about this all the time. Not everyone is born with the same body they have now. I wasn’t born being able to hold a tablet, or speak on the phone, or read. And these are all skills that I have acquired that will probably, I’ll lose one day. It’s all situational. I think it’s just about your body in the situation that it’s currently in. It doesn’t have to involve disability at all.
Nic: Totally. So what got you started in accessibility? How did you become aware of this thing, and how important it is?
Billy: Let’s see. I think it started with me. I started this company called Devlin, it was a web agency in Toronto. I was a front-end developer at the time. And I had just sat down at my desk the first day, and they were like “Here’s the templates. We need to get these fixed up, cleaned up, and accessible.” And I was like “Okay, cool.” So I sat down, I’m like “Just one question. What does accessible mean?”
I had no idea. I had never really thought about it before, like everybody else, you didn’t know until you knew. And then it was explained to me, and I was very lucky at the time. Sitting across the desk from me, well, diagonally across from me, was Joanna Briggs, who now works for Simply Accessible. And she taught me a lot. Derek Featherstone was also on the project, so I learned a lot basically from those two attacking and beating up my code on a regular basis. I learned a lot in a very short amount of time.
And I loved it. As a developer, I loved the way it made me think about my code in a way I’ve never thought about it before. Because when you’re just building stuff to look like the picture, the artwork that you’re handed, you don’t really have to think about it too much. You can use whatever elements work at the time, and away you go. But when I started thinking about things like semantics and structure, I started seeing my code do things that I never thought it could do, and that’s really what drew me into it, the sort of magic I could make that I never knew I could do before with HTML.
Nic: I find that really interesting, because one of the things I tell a lot of people, I’m gonna backtrack a bit. One of the comments I hear a lot is from developers, is that accessibility is difficult, accessibility is a chore. And I flip it on their head, and I contrast them, “Hey, you’re a developer. You like a good coding challenge, don’t you?” And they say yeah. And I say, “Why don’t you think about accessibility as a coding challenge?” And what you’re describing there is exactly what I’m trying to get through to these developers that find it difficult, and they don’t really wanna do it. It’s kind of neat to have a reformed front-end developer actually describe that.
Billy: I like that you use the word “reformed.” But no, you’re absolutely right. I think it is a challenge. And I think Karl summed it up best, and I don’t know if this quote comes directly from Karl, but I’m gonna credit him with it.
We had a room full of difficult developers when we were training together once, and Krl said “Look, we’re not telling you what you can’t do. We’re only telling you that you’re only limited by your own imaginations here.” I think that rings true. I think people need to realize that they can think their way through any problem. Any web problem we have with accessibility, to a certain degree at this point, you can come up with a solution relatively easy. Or if not a solution, maybe a better way of doing it. I think we overcomplicate the questions when we’re trying to look for simple answers.
Nic: Is there only one answer to most problems, you think, in accessibility?
Billy: Heck no. I think there’s probably several. I think the only clear answer is, yes, it has to be accessible. As far as how you make it accessible, I think there’s different ways. I think everybody has different ways of coding a page, or creating a solution. I think some answers might be more elegant than others, but sometimes crude works. I’d rather have a less elegant solution than no solution at all.
Nic: Don’t you think that makes it more difficult for people that want to get started in accessibility, that there’s no single black or white answer?
Billy: Absolutely. I think that’s probably the biggest argument we hear all the time, is that there’s no clear path to accessibility. A lot of developers get frustrated, because they’ll research what they think is a very simple question, like how do I make this date ticker accessible? And they’ll find like 30 different arguments, and a lot of the time they won’t even find solutions. They’ll just find people bickering on Stack Overflow or Twitter or something.
So I think as an industry and as a community, we’ve got a long way to go in terms of making it easier for developers. I think I even saw an argument about this on Twitter earlier this week, someone saying it would be great if we just had somewhere we could go and copy and paste working examples. And there’s a couple of companies out there doing it. But I think we’ve got a long way to go in terms of making it easier for people to embrace accessibility.
Nic: Where does your role fall within the work of web accessibility? You mentioned earlier that you’re the training lead at TPG, and a couple other things. But day to day, what do you do?
Billy: I’m the director of training for the Paciello Groups, so what I do in addition to obviously going around and doing the trainings in person, I manage all of our in-house training materials. So I’m in charge of making sure they’re up to date and consistent. I’m not the one writing all this content. Luckily, we employ some of the best minds in accessibility that I can pick from, and task with creating fantastic materials for me. But I herd those particular cats, in terms of content, and make sure that everything’s there and in place.
We’ve got a few little things that we’re cooking up that I can’t really talk about, but my day to day is basically making sure that everything training related at TPG is running smoothly. That includes making sure we have the proper people doing the training, that the courses that we’re teaching are customized and tailored to the client’s needs, and all that.
Nic: As you were learning about accessibility and you had Joanna and Derek bashing your code, what kind of barriers did you find in terms of implementing accessibility and how did you get over that? How did you cope? What advice would you have for people getting started in accessibility that want to progress?
Billy: I think you need to start with the basics, and a lot of the stuff that I had to do really were the basics. I think a lot of it just came with, I mean, we talk about this all the time. You get so much accessibility for free if you just use the right elements for the right jobs. HTML5 and HTML, all these elements exist for a reason. Figure out what their purpose was, or their intended purpose, and use them in that way. And you’ll start seeing your code doing things that you didn’t necessarily have to do a lot of extra work to get it to do. We have a lot of developers out there that are really talented developers, but they’re not really paying attention to the basics. They’re paying attention to JavaScript, or whatever great library is out there. But they’re not really paying attention to what the output of those libraries are. And I think that’s where a lot of the pitfalls happen. I think people don’t really understand what HTML, what the actual HTML that’s being generated by these libraries. I don’t think they’re paying attention to that.
Nic: I have to admit to you some frustration in that respect. In the last couple weeks, I’ve been finding code that I didn’t know if I needed to laugh or cry. It’s really a question of, go back to the basics. Learn HTML. And it seems like a lot of people think HTML’s not a real coding language, so it’s kind of dismissed out of hand.
Billy: I totally agree with you there. I worked alongside an older, and he was a programmer. He came from an actual software development background, so … I never got the feeling that he felt web was beneath him, but I definitely got the feeling, and he said so in so many words, that writing HTML, that isn’t coding or programming. That’s just markup. Which, I think it was very shortsighted, in many ways. I don’t think people give properly crafted HTML and CSS, to that extent, I don’t think it gets the respect it deserves.
Nic: How do we change that?
Billy: Go back to 2008 and obliterate jQuery? Honestly, I don’t know. I think a lot of developers grow to appreciate what HTML is as they … I don’t wanna say the word “mature,” as developers, but I guess that’s probably the best word. I think the more that they pay attention to what that code looks like, the more they realize how elegant it can be, and what you can do with it. So I think the only way we can do it is really … we can talk about it all we want. It’s up to people to decide that they wanna listen to us. But I think a lot of people will learn that over time.
Nic: Isn’t it gonna be too late, though? Because by the time they learn, they’ve created so much guff that actually doesn’t work from an accessibility point of view, so isn’t their some urgency to get things fixed now?
Billy: Absolutely. But I guess jokingly, we can say that that’s just job security for us. But realistically, I was in my mid 30s when I stumbled, literally, into accessibility. And that’s fairly old, I think that’s ancient by today’s standards of a front end developer. So I don’t think it’s ever too late. I think it’s too late for maybe that particular project, but I also think that accessibility is a lot more in the forefront than it used to be. More people are mentioning that word in meetings.
Back in the day, doubling back to what got me into accessibility, is once that project wrapped, I was keen to do more accessible projects. And nobody wanted to do them. It was not a word that clients wanted to hear when you were meeting with them back then. Now, I think a lot more people are not only okay with hearing the word brought up, but the clients themselves are mentioning it. Maybe it’s because they’ve got a lawyer chasing them, maybe it’s because they just know that it’s the right thing to do, or they’re trying to take some preventative measures. But regardless, we’re hearing clients bring up the fact that they want an accessible website more, which I think is huge and great.
Nic: You’ve said before, and the quote may not be exact, but you said “User experience without accessibility is some user experience, or SUX.”
Billy: Yes.
Nic: That’s quite a striking statement. It’s memorable. And there’s been a fair bit of discussion on there about accessibility and UI/UX, or UI/UX versus accessibility. What would you have to say on that topic?
Billy: I stand by the statement, first of all. I truly believe that … I don’t wanna blame designers for this, because again, you don’t know what you don’t know. But when you don’t consider who is going to be using your site, and by who I mean, you have to open yourself up to the fact that you have no control over it. You don’t know who’s gonna be using your site. So you have to design for the most amount of people.
And that’s why I made that statement, because I saw so many sites that were under-delivering. They get just so close to the point of being accessible, and then there’d be one or two things missing. Just basic keyboard interaction, or focus management, or something that would be on a high level, fairly easy to fix. And I got to the point where, I think it was early new year 2016, or 2015 at this point where I tweeted that. And yeah, I was just at my wit’s end. I had seen so many sites that were just so close to being perfect that I realized that we have all of these widgets and common elements that we just fall short on.
Nic: Do you think accessibility is a subset of UI, or is it a side branch, or what’s the relationship between the two?
Billy: That’s a tough one. To say it’s a subset implies that maybe it’s only that one particular practice’s job. I think it’s a subset of web development. I think it’s an element of all development, no matter what your role in web development is, there’s a portion of that that relates to accessibility that falls on you. And this is nothing new, I’m not breaking any new … we’ve been saying this for years. Accessibility has to be there from the beginning, everyone has to take a role in it. And I think that’s true.
I believe that yes, it is a part of user experience, and that we have to make sure that we manage the experience for that particular group of users. And it’s a very diverse, and no two users are the same. That’s its own problem. But development obviously has to play a role in that as well. We have to get the client on board, so the project managers and the stakeholders there have to do their job to make sure that everybody is working towards the same goal. And it’s great if we get all of that done, but if it falls in front of QA and they don’t know how to test for accessibility, that’s a whole nother problem.
Developers can have all the right things in place, but if QA isn’t knowing that they need to hit this with a scream meter, or even a keyboard, or just to not use their mouse in certain places, then we have all of this work that goes untested. So I really do think that everybody has to have their role in it.
Nic: Everybody has to have a role. Not everybody has a role in UI/UX though, do they?
Billy: Maybe not specifically, but I think there’s probably not a developer alive that hasn’t gone back to the designers with some kind of complaint or another. Usually it starts with “I can’t build this,” and then two days later they have it built. But, you know. I think everybody has a role in almost everything, like designers, that’s the problem. I think we break things up too much and we silo, and we’re really all building the same thing. So I think there needs to be more overlap, and less division between practices sometimes.
Nic: Are you aware of any UI practices that break accessibility, or accessibility implementations that UI specialists say this doesn’t work?
Billy: We’ve heard time and time again that there are definitely elements that are more trouble than they’re worth. We hear of things like drag and drop that sends shivers up almost everybody, every keyboard user’s spine. Carousels have been proven time and time again that just aren’t good. People lose interest by the second or third dot, but people love them because it’s a great way to use real estate for four or five different things. We hear hamburger menus on desktop sites are awful, and people don’t like that. Even [inaudible 00:20:10] apps are their own problem.
There’s definitely enough things out there that are nightmares with regards to accessibility that we might not be able to get away from at this point.
Nic: It’s funny you mention Carousel, and I don’t like them from an accessibility perspective. But I’m thinking that the only person, the only group that really love carousels in the end is the client, because there’s more and more reason to not like them. How do we take an element like that, that a client really insists on, and it’s likely to either break accessibility altogether or make it really difficult to implement? How do we make the client change their mind about something like that?
Billy: That’s, jeez. If you could answer that one, you’d be rich. Realistically, I think if we have a client that believes and is committed to accessibility, some of those arguments become a little easier. Some of those battles become a little easier to win. But overall, we can’t force a client to do something they don’t wanna do. There are ways of making carousels somewhat accessible, but it’s a lot of extra work. So it’s one of those, if we hit the buy in, we can say “Yeah, we could do this. But it’s gonna take this, this, this, this, and this to do. Do you really wanna do that when we could just do this?” Like, maybe there’s more elegant solutions, or …
I agree with you. I just don’t see the value in a carousel outside of the client loves it. And I get why they love it, but realistically, a lot of people have trouble with them. They struggle with them. And it’s not just people with disabilities. I see my parents, who as older users, who are just getting used to the internet now, they’ll go and they’ll try to see as a carousel, and they don’t really get what those little dots mean. And they don’t get all of the little bits. My dad does most of his surfing on an iPad, so it’s tough for him when he sees something and he goes to click on it, ’cause his reaction time is slower. And he goes to click and it changes. He ends up on a page that he doesn’t wanna be on. Then he’s gotta go back, and he doesn’t get it.
I think they need to consider that we’ve got an aging population, we’ve got people with disabilities, we’ve got people who just know that carousels are garbage. And there’s too many people that don’t like them. I think you’re right, it’s really the client that likes it. It’s a tough situation.
Nic: It is quite tough. You mentioned if the client buys into accessibility, how do you sell it to the client?
Billy: Well, like I said, a lot of the time these days, and I’m probably in the wrong line of work, because most of the time either someone is approaching us to make something accessible, or they’ve got other driving factors with regards to why they need to be accessible. Luckily for me, by the time they come, they’re already looking for some kind of solution. But that’s where, unfortunately, I guess we have to lean on things like guidelines and legislation. There are some sales-driven factors in there too, obviously. We’ve shown the drop off rates for people using assistive technologies with some sites. It’s pretty steep. We know that people get fed up easily. All of that plays into a good user experience, and the more usable your site is, the more traffic you’re gonna get.
Nic: Yeah. I think there’s a good business case for accessibility, but it’s hard to phrase and quantify. And I think that’s one of the problems most of us in the accessibility community struggle with, is being able to quantify the business case for people.
Billy: It’s a tough one.
Nic: Hey Billy, on that note, I think we’re going to wrap this segment of our conversation. So I’d like to thank you for your good answers and the discussion this morning. We’ll finish our chat next week, if that’s okay with you.
Billy: Sounds great. Looking forward to it.
Nic: Wonderful. Thank you.
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.