Derek Featherstone Jared Spool: I'm here at the Webmaster General Conference in Dallas and I'm talking with Derek Featherstone, who is the closing keynote speaker at the conference. And he is from Ottawa, Canada. He's probably the guy on this planet that I know of that is the most authoritative in the area of implementing accessible websites. He really understands what this is about. And I though we'd take a moment and talk to him. Hi there, Derek. Derek Hi, Jared. Featherstone: Jared: So you're from Ottawa, you've got clients like Business Objects, John Hopkins University, the United Methodist Church, and a whole bunch of financial institutions. And for these guys, a lot of your work, you do website design. But a lot of your work has to do with looking at and making sure their systems are not just useable, but also accessible for all sorts of different disabilities. Often times when people think about accessibility they tend to just focus on vision issues. Screen readers is mostly what we hear about. But that's just only a small piece of the accessibility picture, right? Derek: Yes, it is. It's a small piece and that is something that is quite often overlooked. People tend to think of screen reader compatibility is what they're providing by providing an accessible website. And really, it's much more than that. Creating something that is technically accessible and also useable to people that may use a touch screen -- because they may be in a wheelchair -- and they use a touch screen to access their sites. They may be using voice recognition technology. They may be using a mouth wand or a head wand to type or to interact with interfaces. So it is definitely much more than just creating something for people that are visually impaired. Jared: So building these systems out, when you're thinking about this stuff, you're really sort of looking at the different ways people interact and sort of taking into consideration: have we done a decent job of dealing with the scenario that someone might be using a touch screen, not necessarily using a mouse, and might not have completely fine motor control or very single pixel point to be able to select something. Derek: Right. Yes, definitely. So it's really something where we can do all the things that we want to make a site technically accessible and then we start to look at it, taking it a little bit further, and how to make it so that we can ensure that somebody can actually use the site. And that's where we want to make sure that we go the extra mile to make sure that not only are we doing something technically right, but we're actually providing something that people can use, and not just have the ability to use, but they can actually use it in everyday life in practice. Jared: Right, OK. So last night we were talking and you were telling me about a client who called you. And their question -- you had designed their site previously -- and their question was about upgrading the site for accessibility. Can you share that story? Derek: Yes, it is quite interesting actually, because one of the companies that we do work for is a conference company and they do a lot of conferences for government employees and the public sector. And one of their new prospective clients is a municipal association that wanted to ensure that any websites that were built for the new conference were accessible. And the theme of the conference was accessibility itself. Jared: Yes, so you'd want to have an accessible website for an accessibility conference. Derek: Exactly. So the client called us up and said, "We have a question for you." And they said, "What will it take for you to make one of our conference websites accessible?" And I said, "Well, they already are accessible." And he was literally flabbergasted. He had no idea that we had already done this just because it's the way to build a website. Jared: And this wasn't a big-budget client either, right? Derek: No, not at all. Jared: This was a client that you had done a project, that was just a normal project, you'd priced it out, and you'd made it accessible just as part of your normal practice. Derek: That's exactly it. This is the way that we built sites now. We do this, we have our setup for their conference websites and we reuse a lot of what we've done before because we know that it's solid and it's going to work. There are a few things here and there that we may tweak sometimes. Some color issues may need to be tweaked for one particular conference to make sure that there's enough contrast in certain areas, but for the most part, their websites are already accessible. And it was quite gratifying because they didn't even know. They didn't realize that we had already built it in and baked it into the process. Jared: You could have just charged them. [laughs] Derek: We could have, but didn't. Jared: Good for you. So they put out the bid for this thing, you responded, you built a website, they didn't ask for accessibility in the original release. Derek: No. Jared: And so in essence, you gave it to them, one could say, for free, right? Is it the case now where we have the technology, we add stuff where it's either free or close to free in our development process if we're paying attention? Derek: If we're paying attention and if we're doing the right things from the outset, then yes, there's a lot of it that does come for free. And the nice thing about it is it's kind of like open source. You have open source software and you use open source software, you get all that system, it's already built for you. So you can spend your time and your effort in other areas because you're not building everything from scratch. Jared: Right. Derek: It's kind of like using appropriate techniques and using web standards gives you a certain amount that is just built into that methodology. And so because that's there and you get basic operability, you get basic accessibility, that is in most cases more than enough accessibility for most document-centric sites. It's not always the case for transactional sites, but it's certainly for document-centric sites. A lot of it just comes with the process. Jared: OK. So you were telling me last night about talking to one of the developers for the Microsoft Surface, the big tabletop computers, as one of the parodies put it, "You can now buy yourself an expensive big-ass table." Derek: Yes. [laughter] Jared: Who needs a little pocket computer when you can get a big-ass table? So they've got this thing. If people haven't seen it, it's basically this tabletop computer. So you're looking down at the tabletop at the display. They have these demos which you can find on You Tube and places that are actually very slick where people are using their fingers to move items on the display around. More than one person can manipulate stuff because they're at the table at the same time. They have this technology where a company like T Mobile and their stores could have this as a demonstration table. And you could take one of the models of their phones and put it on the table and tell you all he features in the phone. It will somehow read the phone. The demos are very slick, but you told me that you actually talked to one of the developers and asked them about accessibility. Derek: Yes, I did. It was interesting because I can't remember exactly what her role was, but being an accessibility person, I was really interested in seeing this new interface and how it works. Jared: It has such potential for a lot of stuff. Derek: It really does. Especially when you see some of the things with somebody putting a phone on and it reading that phone, it immediately made me think, "OK. What if a person that's visually impaired has their phone and they but it down on there. And some preferences are stored in there, in some way, that kicks this surface table into some other mode where it enables some additional features that might really be useful?" Jared: Yes, that would be really hard for someone who has motor issues, or has vision issues, or even potentially hearing issues, right? What if it had TTY capabilities built right in? Derek: Exactly. Jared: That would be very cool. Derek: There's so much that you could do with it. And so that's what I really wanted to get into, you know? Is to find out: is there a headphone jack? Is there a way that somebody that's visually impaired could plug into this? Is there a way for sound to be used in the interface to compliment? What's happening on the screen to let people know when they're near a hot spot or something on the screen? Or even things like how does the touch surface react to somebody that may have a prosthetic limb? Jared: Right, yes, of course. Derek: So there's all these things that I was really interested in and really wanted to talk about. Jared: Right, because like iPhones apparently, the touch screen doesn't work if you're wearing gloves. Derek: Interesting. Jared: Right? So an iPhone is not going to be very useful. So I wonder, I don't know about these tables. Derek: And that's why I wanted to talk about it. Because I just find it fascinating, exploring these alternative new interfaces. So I was talking to her and I said, "Who's in charge of accessibility? Who's looking at the accessibility for Surface?" And she said, "Oh, it's me. I own accessibility." And I thought, "OK, interesting choice of words. You own accessibility, that's a business term. Fair enough, I understand." And I said, "Well I'd love to talk to you about the accessibility of Surface, what's happening with it." And her response was, "It'll be compliant." Jared: It'll be compliant? Derek: It'll be compliant. And I thought, "No, no, no. But let's talk about the accessibility issues with Surface. I'm really interested in the research side, the engineering side, and all of these different sides." Jared: What have you guys thought about, what do you still have open that you haven't thought about that is probably on your drawing board? Derek: Exactly. And that's what I wanted to talk about. And the answer that I got was, "It'll be compliant. It's not right now, but when it launches, it will be compliant." Jared: You know, and the thing is, that notion of compliance, it shows that people haven't really thought about this. They know that they have to deal with it. But they haven't integrated the idea that making things accessible is really a good design goal. You know, this idea that: OK. My resources are all busy right now as it is. We can't get all the stuff that's on our plate done. And we haven't even thought about accessibility stuff, but we have to do something about it. Let's just make it compliant. I mean, that's what I'm hearing from this. I've seen that attitude other places. In your mind, is there a difference between being compliant with the accessibility guidelines that are out there and actually making something accessible? Derek: Yes and no. At the core of it, compliance is generally seen as a QA type issue. It's quality assurance. Jared: Right, by definition, right? It's meeting the requirements which, you know, and sort of quality assurance process is all about establishing requirements and then meeting them. Derek: Exactly. So, you know, from a technical perspective, you could say that something that is compliant with these guidelines is accessible at a technical level. Really where I'd like to try and take it is taking that next step. Because something that is technically accessible may be completely unusable, completely unintelligible to somebody, the content may not make sense because of terminology and because of whatever the person's understanding, their domain knowledge, whatever it is. There's a lot of different things that contribute to the usability of something for a person with disabilities. And that's where we start to look at things in a little different light. Because when we start to not focus on compliance and we start to get things back and get right into testing with the user and the person that's actually using the interface, whatever it happens to be, when we test with real people it becomes much more than a cold, stark, compliance, Q&A issue. Jared: Right. So that's true. When you're thinking in terms of compliance, you're thinking in terms of meeting rule 17, right? You're not thinking that there's a person out there that has a situation. Now one of the techniques that a lot of design teams use now is personas, right? So you create these personas. And it's interesting, because I haven't seen amongst the teams that we've worked with really much effort put into personas where people had disabilities or issues that they were working with. And this is something that I'm realizing that I'm not taking into account, every persona that we've been seeing is -- they have all sorts of attributes, but it doesn't say, "Oh, and by the way, they're paralyzed from the mid-waist down, they have limited upper body movement, and therefore, using a mouse is impossible." But that wouldn't be hard to build personas out with those types of things. Derek: No, not at all. In fact, some of our clients that are already using personas, we've been working with them to build some additional attributes into the personas so that the accessibility issues become less of an afterthought and more of something that's built in from the beginning so that everybody's on the same page. Jared: Right. And it's the same thing, right, in terms of dealing with compliance verses dealing with accessibility? If you're dealing with a persona where you have someone who has motor issues and is dealing with that stuff, then you can sit and ask the question like you do with any persona description and say, "Will our design work for this person?" Because that's the purpose of personas and because you've got that to find out at a level of detail and at a level of granularity where you can actually think in terms of that verses just rule 17 says buttons have to be this many pixels tall. It's a completely different sort of thing. Derek: Absolutely. I couldn't have said it better myself. I mean, that's exactly it. If we embrace it at the persona level and we're creating personas at the beginning of the project, if we do that and we can carry that through all the team meetings, all the development process, all the design process, then we're in much better shape and not even dealing with it at just a pure compliance level. Jared: Right. Now, the browser technology is actually helping us these days, right? Derek: It is. We've got new browsers out there that are becoming more popular. Like Firefox is becoming infinitely more popular. Jared: Right. More visitors visit our site with Firefox than any other browser, which I find fascinating. Derek: That is, that's very interesting. It's something where we can use technology that's available to us and Firefox to create one-off solutions if we need to. Just as an example, I was at a conference in Chicago speaking at an event party. And at the after party I was talking with a couple of people that were interested in accessibility. And one of them was talking to me and telling about his sister who was quadriplegic, in a wheelchair, but had the some motion in her hands. She was able to have some mobility there. And so I asked him what assistant technology she used. And I was expecting him to say voice recognition software. But he actually said that she uses an on-screen keyboard with a touch screen. Jared: Very cool. Derek: So she uses a touch screen and she has enough mobility in her arm that she can use -- she doesn't extend her finger but she can use her knuckle of her index finger to tap the screen and perform all the actions that she needs. Jared: Well, that's cool. Derek: It is. And so I asked him, I said, "Well what's the most difficult part of using the web for her? What does she find most difficult and frustrating?" And he said, "Radio buttons." And I said, "Well, what do you mean?" He said, "Well, she has a very tough time selecting a radio button because it's such a small target on the screen." Jared: Right. Most browsers run their radio buttons very small. Derek: Exactly. Jared: And the operating systems tend to do that. Derek: Exactly. So... Jared: Because they're designed for a mouse which has single pixel resolutions. So if you're 10x10 you've got a fairly decent height there. But on a touch screen, particularly with a higher resolution touch screen, 10x10 is a really small space. Derek: It is small. And so he was telling me that her base problem is selecting radio buttons because they're too close to one another. So it's very difficult for her to select one out of group of say, five. And I looked at this, I started thinking of all these different ideas, you know? How can we work with this? And I started thinking about lots of different ways where we could write a script that would automatically figure out that a radio button is there, and here's the label for it, and we can expand it and do all these things. And then just thinking about it I asked him what browser she was using and she uses Internet Explorer. And I said, "Well, what if I told you that we could do something in about three minutes that would make a world of difference to your sister?" And he said, "I'm listening." And so I suggested that they get Firefox browser and email me because eventually, ultimately, what I did was create a users CSS style sheet where it basically targeted in the page, it found any radio buttons, and instead of making it them the default size, it made them four times that size, and it automatically created a margin around it. So there was more space in between the radio buttons. Jared: Right. Derek: So she can load that into her browser in Firefox at any time a radio button was on a page. It would automatically space it out more and make it bigger. So it was just something where the radio buttons themselves could have been perfectly, technically accessible with labels and done the right way. But this little hack that we can build into Firefox with a user style sheet could make a huge difference to this person. And not make it any more technically accessible, but it's a heck of a lot more useable. Jared: Right. So that's cool that the browsers are now letting us do this sort of thing. And that does ask the question as site designers, you know; right now we have to do a lot of stuff, because these user side-type solutions are not generally available. But as more of them become available, it might actually make our jobs a little easier. And just knowing that these things are out there and knowing how they work, we can just code to them and when users are using them it takes advantage. Derek: Yes. I mean that's the beauty. The reason that we can do that is if we have a foundation of standards based code then we've got the ability to go in and do these one offs after the fact. Jared: That's right. Derek: And if we had a massive jumbled code, it makes it much more difficult to provide some of these one-off solutions that we can provide with some of these little pieces of code that take two minutes to generate. They can make a world of difference. So it's something where I think more and more people will start looking at the service that they provide and provide a standards- based solution to begin with. And then have it almost like multiple formats policy that a lot of departments, government departments have where, "Here's our core version. If you need some alternative version let us know and we'll gladly provide that to you." Same kind of thing, "Here's our core version. If you need any modifications to it then maybe we can provide you with this little extra script that takes two minutes to write." Jared: Right. Cool. So teams that are thinking, "OK. We definitely need to be adapting our practices to this." How do they get started? What's sort of the first steps to getting going and do you have suggestions for resources or places to turn? Derek: Yes, there's a lot of really good blogs out there that talk about accessibility and they have specific samples of how to deal with things from a code perspective. That's sort our starting point is making sure that our code is exactly like it should be. Jared: What's your favorite of those resources? Derek: One of the best ones historically is - two really -- is Accessify.com. Jared: OK. Derek: And then WebAim, which is WebAim, W-E-B-A-I-M.org which is a shortened form of web accessibility in mind. Jared: Cool. Derek: And those are two really good resources where there's lots of content going up there all the time, and news on what's the latest in accessibility, and what's happening around the world. So they're really good resources as starting points. And in terms of the actual building and implementation process, the WC3 has a checklist out there, compliance guideline, and as much as I think that their compliance mentality is not necessarily where we want to be, it really is a good starting point. Jared: Yes. So it's a place to start, right? Derek: Yes. Jared: Understanding not just what the rules are, but why those rules came about and who those rules are affecting. Derek: Exactly. Jared: And then asking the questions in addition to just complying to the rules: are we really providing the interfaces that people can use? Derek: Exactly. And that's where what it comes down to is that the checklist and the compliance guidelines are a starting point, not an end point. Jared: Right. Derek: And that's where when we start looking at it that way, that's when we can built really, truly useful, and accessible interfaces for people that need them. Jared: Super. Now if people want to get in touch with you, talk to you about their projects, how would they do that? Derek: They can contact me through my website, FurtherAhead.com. Jared: FutherAhead.com, OK. We'll put a link to that on the show notes. Derek: Perfect. And we've got a list of upcoming events, conferences, and workshops and things. And newsletter sign-up as well so that people can keep up to date with what's going on, where we're going to be, and the kinds of things that we're working on. Jared: Super. Well thanks for taking the time to talk to us. Derek: Thank you.