As part of Knowbility’s 2013 John Slatin AccessU, we are proud to present an interview with Karl Groves—one of my co-workers, and speaker at the upcoming AccessU. Karl works on our team as an Accessibility Consultant and is interviewed here by another co-worker, Derek Featherstone. They talk Vikings, testing, workshops and BBQ.

Here’s the second instalment in our series of AccessU 2013 Speaker Interviews:

An interview with Karl Groves

Feel free to download the podcast:

Karl Groves interview transcript

This is the transcript of an interview recorded on April 19th, 2013 between Derek Featherstone, and Karl Groves, an Accessibility Consultant here at Simply Accessible. It was recorded over Skype and posted as part of John Slatin AccessU 2013 podcast series.

Interview summary

Derek: What do Vikings, user testing, forms and BBQ have in common? Karl Groves. Listen in on this conversation with Karl and learn more about his upcoming workshops at AccessU.
Coming up May 14th to 16th in Austin, Texas, presented by Knowbility, this is THE conference to go to for in-depth, hands-on, minds-on accessibility training. Check it all out at That’s k n o w b i l i t y dot org.

Here we go…

[Intro Music]

Derek: This is Derek Featherstone from Simply Accessible and I have the distinct pleasure of talking with Karl Groves, who is one of my coworkers here at Simply Accessible. We’re talking about getting ready for AccessU coming up in Austin, Texas, May 14th, 15th, and 16th, put on by Knowbility. We wanted to take some time to talk with some of the speakers and help everybody out there that’s listening understand what the conference is about and why it’s one of the (if not the very) best accessibility conferences. If you’re brand new to accessibility or if you want to go deep into it, this is the place to be.

Karl, we’re going to talk for about 20 minutes and have a good time doing it. How are you doing today?

Karl: I’m doing excellent today. Thank you.

Derek: That is always good to hear. Karl and I work together, so we get to talk like this every day and Karl is always excellent, so today is no exception.

Karl, I know you pretty well, but there are some people out there listening that probably don’t know you even though they should. Can you give us a quick rundown of who you are and your approach to accessibility? Then we can take it from there and move into some of your talks that you’re going to be doing at AccessU.

Karl: I actually got into accessibility by way of being a web developer. I started my career in web development, somewhat ironically, in the DC area right around the time Section 508 started becoming enforced. It came out in 1998 and then they had a two year grace period. I think it was probably that two year grace period that everybody sort of had it out of their minds, and then all of a sudden here I am looking for a job when everybody did start caring about it. So I had a need to actually know this stuff because I was trying to get jobs in the DC area doing web development. That’s how I got into it.

Honestly, I knew literally nothing about it. At interviews they would say, “Is this stuff such-and-such compliant?” and I’d say, “Yes,” because I wanted the job. I really didn’t know much about it at the time and I needed to, so I found a whole bunch of resources out there. UseNet was still around, also the WebAIM list, which is the first time Derek and I actually interacted with each other, about a decade ago now.

That’s really how I got into it was because I had to. So I have a developer’s perspective for the most part with it and that’s where I really come from.

Derek: I know we’ve talked about this a little bit before. You also in some of the jobs that you’ve had previously, you said you had worked at an organization where your entire focus was on the user and you had a very user-centric view. You had that user experience flavor, probably before it was even called user experience. Can you tell us a bit about how that comes into your history and also how that influences your work now?

Karl: It’s funny, because I got a job as a web developer for a small usability consulting company and the reason was because the owner of the company was doing usability consulting but didn’t do much development, and he had lots of calls for people to say, “You’ve told us what’s wrong. Can you fix it for us?” He started realizing that there was some business value of being able to do that in-house as opposed to farming it out.

About the time that we were talking about my doing sign work for him, he got a very big contract with a sub-center, they had 16 centers within the National Cancer Institute and one of those centers had hired him to do this website, so I came on full time.

In that process, over a period of about five years, we did lots of usability work and usability studies. I would do lots of functional prototypes for revised designs and stuff like that. It really did get to a point where I was doing as much as usability work and IA work as the other non-developers on the team. It was really eye opening, because you realize that, yes, there is somebody on the other end of this.

That definitely helped shape my perspective as a developer that I do need to make this for people. The Section 508 compliance stuff stopped being so much about compliance and it started becoming more about usability for everybody.

Derek: That’s cool. I love that perspective, because I think a lot of us – I know when I first started as a developer – don’t naturally think about what the consequences are of some of the code that you create. Then when you actually start working with people that are using the designs and the prototypes and/or the full blown sites that are fully coded and production ready, it’s not until you actually work with some of those people trying to use things that your mind gets totally blown and you shift into this other mode where you start to think a little bit more about the ultimate consequences of what you do on how people can actually use things.

Karl: It’s funny you say that. I started out watching a lot of the usability studies that we were doing from the observation room and taking notes. That’s where I got to see real people, not geeks and developers like the rest of us. When you’re talking amongst your friends when you work in an industry like this, all your friends are probably power users – my own wife is a power user. It’s one thing to see somebody who knows a lot about computers work on something versus a person in the general populous who is probably actually going to use your site instead and seeing the difficulties that they can have. It was really eye opening for me, for sure.

Derek: It is, I think, for most people when they experience that.

You have a few sessions coming up at AccessU and I wanted to give everybody that’s listening a little heads up as to what’s coming and what they should expect from your sessions. One of your main conference sessions is called Viking Accessibility, the Warrior’s Approach to Hands-On Testing.

I think you’re probably really well known for your thoroughness and accuracy and everything that surrounds testing. I’m really kind of excited to see that you’re doing this. This is a hands-on lab type workshop scenario for that one, correct?

Karl: Yes. That’s going to be a hands-on testing session with a lab, so there’s going to be desktop computers there for everybody and we’re going to actually go through some specific scenarios of testing.

I think the whole Viking thing is sort of funny, especially because of the many misunderstandings about Vikings. Did you know that Vikings actually weren’t dirty like Hagar the Horrible, the cartoon character that we see in the comic strips? There’s an Arab scholar who wrote on the Vikings and did some historical work on the Vikings and they were actually well known for being clean. They used to carry clean clothes when they were on their excursions to go conquer. I thought that was really funny to hear.

We all know that the horned helmet thing is sort of a myth, because that’s just bad for fighting. But the cleanliness thing I thought was really funny.

Derek: I had no idea.

Karl: The thing that I like about the whole Viking persona is that I look at it more like preparedness. Like I said, they were well known for being dirty and monstrous and all that, but I don’t think that was really the case. But if you read through, there’s this air of preparedness. They were required, for instance, to carry a weapon with them at all times because you never know; they would have to be prepared.

They were also serious craftsman. If you’ve ever seen any of the ships that they built with the dragon’s head on the front of the ships, I think that was incredible. I think I’ll keep the whole Viking thing that Elle gave to me, because I think that we’ll see that in this lab too, this idea of being prepared to do a thorough job. And we’re going to provide tools and hints, and I’m actually going to provide an idea on an accessibility tool that people may not be well aware of that I think does a phenomenal job. It’s actually mostly in the hands of developers and not accessibility people.

Derek: That sounds cool. That’s one of the things that I know we’ve seen in our work is that a lot of accessibility issues tend to be process related and there are things that when the code is in the browser it’s already too late. We want to do as much as we can to move accessibility earlier in the process. So I’m interested in hearing a developer’s tool would actually help improve accessibility.

Is there anything in there, like a little teaser that you can give us in terms of what kinds of things that tool will help you to do earlier in the process that would be really powerful for a developer to use?

Karl: The thing about this is that it really couldn’t be simpler in terms of finding the problems along the way. That was one of the things that previously when I talked at AccessU – this is actually my fourth year – it was all me talking, me lecturing, me saying all this really thorough stuff that I think is great but that really went over people’s heads. Although, I always got great ratings from it, I never felt like people were walking away as prepared as I’d like them to be. That’s why I changed it this year.

The one thing I wanted people to be able to do is just to be able to do things that will let them find out firsthand exactly where the problems are in the most simplest and quickest of manner. Hopefully this can happen upstream with the developers before it even gets to QA.

Like you were saying, that’s really where we want it to be, because once the train has left the station on this code you’re not going to pull it back. If we can get everybody testing as simple as possible, as quickly as possible to get the really high level, high impact things discovered first, I think that’s going to be better from both a project perspective and from the user perspective.

Derek: That sounds like a really good overview in terms of the three hour workshop. You also have a full day workshop called From Stem to Stern, in terms of building and designing accessible forms. I think that’s a really interesting one because forms are so critical to pretty much every interaction online.

What’s the idea or what’s the goal behind the full day forms workshop? I want to dig a little bit deeper on this one. What’s the objective, what are people going to get out of it by the time they’re done that day with you?

Karl: There’s a whole bunch of things dealing with forms that you have to consider, not only when you’re designing them and producing them, but just the whole concept of what the form is going to do, what are the business requirements for it, all these things are really important considerations.

We’re going to be talking about creating the forms, how forms should be laid out, how we can allow users to fill out the forms more effectively. This is for all users, of course. More efficient, more effective, error resistant for lack of a better term, meaning we’re going to figure out ways to allow people to avoid errors in the first place, but also recover them from effectively.

We’re going to be talking about everything from simple approaches for layouts and labeling to much more advanced stuff like validation and feedback.

Derek: Literally from stem to stern everything that people need right from the design stage where we’re talking about layouts and different things that people need, all the way through to the actual building.

I’m not sure whether this will fit in your testing three hour workshop or in the full day, but are you going to work in a whole bunch of stuff on testing of forms?

Karl: Yes. We’re going to make sure that as we’re creating these things that they work properly for all users. There are lots of newer techniques that are out there for creating stuff, we want to make sure that they work in all the assistive technologies.

We’ll talk about some of the ways that certain features work well for assistive technologies, whereas they don’t work for others, and how to test for that and check to make sure that those things are working for all users.

Derek: Nice. I just want to clarify here. When you say different assistive technologies, what different technologies are you going to bring into the workshop?

Karl: We’ll actually be talking about screen readers. Obviously that’s what people think of when they think of assistive technologies. But also different types of screen readers, different versions, voice recognition, and screen magnification software as well. There’s going to be lots of implications for usability for all of these different populations depending upon how you can structure forms, what kind of markup you use, how you lay them out, and those sorts of things.

Derek: That’s cool. I know that’s one thing that we’ve seen in our work before is a significant difference in terms of things that work really well for one piece of assistive technology and don’t necessarily work for another. I guess you would say that more holistic approach where we’re taking into account much more than just screen readers is a critical piece to the big picture.

In that full day then they’ll have the opportunity to test forms, to go through all kinds of different concepts in terms of layout and design. I know one of the things that you and I have talked about before is when we get into that error state with a form we need the ability to easily use those error messages and validation messages to correct those errors.

One of the things that we’ve also talked about before is the entire concept that an ounce of prevention is worth a pound of cure. I’m thinking that you’re probably going to talk a little bit about that, just because I know you and I know you’re going to build some of that in. Do you want to talk about that for a few minutes?

Karl: We were talking about this recently with what we’re doing with a client that we’re working on now. There’s a form field that comes up within a modal dialogue, for instance, and there’s no skip navigation to this thing. You sort of get a picture that this is already sort of problematic, but then you actually get to the form and it’s only one field in this form.

You get to the labeling on this one field and there’s no label. You get there with the screen reader and it just says “edit text” on VoiceOver and JAWS. You get to it and you have no idea until you start using other commands to read adjacent text to find out what’s going on.

A country specific postal code is what they’re looking for and they’re requiring a certain amount of characters and spaces. If you do anything other than that then you’re not going to be able to submit the form. And then when you do submit the form it will allow you to submit it, but it won’t actually do anything for you. When you submit the form then an error message appears, but because the page itself posts to itself you actually have to go back through all of these links, and I think there’s somewhere on the order of 75 or so links just to get back to the form where you were to get to the error message. It’s really challenging.

That’s one of the things that a lot of people don’t realize when it comes to forms is that the first thing that we want to be able to do is make sure people don’t commit the error in the first place. We need to make sure there’s a good label, we need to make sure that any special formatting or any special requirements for each individual field would be disclosed to the user so they know what they’re doing so they don’t have to go through all this stuff to find their error and figure out what the problem was, they can type in the requisite information in the proper format, submit it and move on.

That is definitely a very big component to this workshop is just making sure that we’re allowing people to avoid the problems instead of how we’re validating and all that stuff. Allowing them to not even make the error in the first place is really important.

Derek: I think that’s exactly it. It needs to be that way and I think that’s something ultimately when you focus on that you’re not focusing on whether or not the form is technically coded correctly or you’re validation messages are coded correctly, you’re actually worried about whether or not they’re going to know everything that they need to know in order to be able to fill out the form in the first place and do it without error.

That’s really taking things to a different level. That’s not about compliance, that’s about how easy this thing is to use. I think that perspective is something that I’m always happy to hear more about, because too often it seems to me that people think that it’s all on the developers and it’s all about the code. In reality it’s much more than that.

Karl: And it’s not just an accessibility thing either. In this type of scenario that I was referring to, this is going to be the kind of thing that’s really helpful for mobile users. We know that mobile use is exploding and that people talk about what they refer to as situational disability, meaning that in a specific situation you’re experiencing something similar to what a disabled person would be experiencing.

On a mobile phone, for instance, you’re only getting a very tiny view of the screen, you may have problems with focus. I’ve been using phones for a long time, but I’m still probably the slower texter in the world. These are the kinds of things that are beneficial not just for persons with disabilities, but for all users.

Derek: I think that’s something that we’ve probably seen before and I think it’s a huge benefit for people that are looking to make accessibility a part of what they do. This is not an investment in what everybody seems to think of as a small population. It’s actually an investment in improving the user experience for everyone. Very cool.

Any other thoughts about the workshop or things that you want people to know about either one of your talks?

Karl: I think that both talks are going to be hugely beneficial for people who are just getting into accessibility. The accessible forms toolkit is going to have some geek-speak in it, but nothing that is going to be beyond basic HTML and CSS knowledge. We’ll talk conceptually about some javascript stuff, we’ll even show some of that sort of stuff. But it’s not going to be over many people’s heads.

The testing one is going to be hugely beneficial for developers and QA people. I would encourage anybody who is thinking about these sorts of topics. If your site has a lot of forms then you’re definitely going to want to make it to the workshop. If you have to do testing or validation or ID and V on your stuff, or stuff that’s delivered to your company or agency prior to acceptance, then I think that’s beneficial for people as well.

Derek: Excellent. So you’re going to be in Austin for a good three or four days. What is your must-do or must-have thing while you’re in Austin? There are a lot of people that aren’t from Austin and we want them to make their way to Austin from everywhere. What should they be looking for as they’re visiting?

Karl: I absolutely hate myself if I leave Austin and I haven’t been to The Salt Link.

I think of The Salt Lick as the Disneyland of barbecue. If you go to the original Salt Link there’s this huge parking lot and all of these cars. I always think maybe they should put up little signs, “You’re in the Scooby-Doo zone,” or whatever because it’s so big. Then you walk in there and the barbecue is just phenomenal.

Like I said, I’ve been to Memphis many times, I’ve been to St. Louis, I’m sort of a barbecue aficionado, and I think The Salt Lick’s ribs are the best ribs I’ve ever had. Of course, they do have the standard Texas barbecue stuff, lots of beef based stuff, brisket and all that. But I love their ribs, and they have both beef ribs and pork ribs.

The other one I like, last time I was there I also went to Iron Works, which is down by where they have SXSW. Iron Works is really good. Last time I was there, you can buy their ribs and bring them home to cook them or you can buy their rub, so I bought their rub and Jen made some ribs.

That’s the big thing for me.

One more. One of my favorite places, Jim Thatcher took to a place called Esther’s Follies. Have you ever been there?

Derek: I have not.

Karl: It’s in the downtown bar area. This place Esther’s Follies is really great; it’s a live stage comedy review. It’s not really like a standup thing, they have skits and stuff like that and they do a lot of political satire. It’s great because it’s non-partisan political satire. You can tell that they’re more liberal than conservative, but they make fun of everybody and it’s just hilarious.

Derek: That sounds awesome.

Karl: Those are my favorite Austin things.

Derek: Thank you very much, Karl, for taking the time. Have a great time at AccessU.

Karl: Thanks a lot.

Derek: There it is. Karl actually worked in a reference to Hagar the Horrible. Get yourself to Austin for some great BBQ and AccessU.
Get all the details at – that’s k n o w b i l i t y dot org.

[Outro Music]

Links for places mentioned in the podcast

The Salt Lick:

Iron Works:

Esther’s Follies: