By: Kevin Yank

October 3rd, 2008

Reader Rating: 9

At the Web Directions South conference last week, SitePoint’s Kevin Yank had the opportunity to speak with Derek Featherstone [1], a well-known web developer, author, and accessibility advocate.

Derek presented on the topic of “Accessibility Beyond Compliance”, and in this interview revealed more on his motivations for educating other web designers and developers about real-world accessibility. You can download the audio for this interview [2] (MP3, 11.1MB), or read the transcript below.

This is Kevin Yank from sitepoint.com, and I’m sitting here at Web Directions South 2008 with Derek Featherstone, who gave a brilliant talk on web accessibility just yesterday. Hi Derek.

Hey Kevin.

Derek is one of those people who doesn’t just talk the talk when it comes to accessibility, he walks the walk—or runs the triathlon, as the case may be. Do you want to talk about that project of yours?

Yeah, sure. My wife and I started doing triathlons. We wanted to have a web site that we could share our journey on, with our friends and our family, and so we decided that we wanted to create a blog that shared not just our stories but also our photos and some of the data, if you will, from our training.

So we would keep track of all our training runs and bicycle riding, and keep track of all that and then upload it to the site and try and present it in a way that was a bit creative and interesting. We mapped out all our routes using Google Maps, and we’ve got that data on there and it tracks our position, it also shows our heart rates and the altitude and all sorts of other wonderful pieces of data about the training rides that we did.

And so this is your second time presenting at Web Directions South, and last time you were here everyone came away talking about the crossword puzzle example—how you took a crossword puzzle that presented in a very visual way, but also made it accessible and interesting for non-sighted users.

Right.

This year it was taking Google Maps and making that more accessible for those users. Do you go after these problems actively, or do they seem to come to you?

A lot of them, they’re… this type of problem is something that just presents itself to us through our everyday lives. We have problems that we need to solve, either whether it’s for a client or it’s something that we see where there’s a problem with the accessibility of a particular solution, or something like Google Maps.

We want to make them more accessible than they are by default. So we looked at it and decided, well, let’s solve this problem—and not necessarily solve it for everyone, but let’s at least make it more accessible than it currently is. So there is a bit of that serendipity that these opportunities present themselves to us, but quite often it’s for a specific need.

Having said that, there are definitely times where we go and we hunt things down and we know there’s a problem with X, let’s go and figure out a way to solve it. And we’ll put some time into it that way.

How closely do you follow things like the accessibility arguments that go on in the standards bodies like HTML5 and stuff like that?

I follow them on the periphery, so to speak. I don’t get embroiled in them. I think… To be honest with you, I’d rather spend my time doing other things than arguing over the fine-level details. There’s enough… In my mind, there’s enough people doing that already, so I would rather spend my time fixing things and building cool stuff than arguing about some of the minutiae. I’m not saying it’s not important, but it’s just not where I want to spend my time.

Do you notice a difference between accessibility as it’s talked about by well-meaning developers, who may not have personal experience with those challenges, and the problems that you face when you talk about accessibility?

I think one of the things that I find is that there are a lot of people that do mean well but they don’t necessarily have the experience working with real people with disabilities. So quite often their feelings are based on, or their opinions are based on what they assume rather than what they’ve seen and experienced. And I’m certainly not saying that some of the things that we do aren’t based on assumptions and opinion as well, but we do try to do as much as we can with real people so that we have that informing that opinion.

So a common assumption is that accessibility means screen readers, for example?

Yeah, exactly. And, yes, accessibility is important for people that are using screen readers, but there are other technologies that need to be taken into account. We need to take into account the needs of people that might be using voice recognition software, or they might be using screen magnification software, and their needs might be slightly different and/or completely different from people that are using a screen reader.

Voice recognition is a new element that I noticed in your talk this year that you didn’t speak about when I last saw you. Is that something that’s on the rise, or has been newly adopted in the past couple of years, or is it just something that’s jumped up on your radar?

It’s definitely something that I think is on the rise. People that I talk with, there’s a lot more discussion about repetitive stress injuries, and there seems to be an increase in the number of people that are using that type of technology. And it’s something that I specifically choose because of exactly—as you said, most people think screen readers when we talk about accessibility.

I think it’s really important to highlight, in this scenario and in these forums, that it’s more than just that, and we need to showcase how some of these pieces of technology work so that people can walk away with more understanding and more knowledge of the types of challenges that people using that type of software would face.

Yeah. Voice recognition, I think it’s particularly accessible as an accessibility technology because it’s the kind of thing that has some wow factor that even a non-disabled user would maybe have a play with it and actually use it significantly in their day-to-day work.

Absolutely.

Speaking about rich web applications, what I notice is that a lot of the guidelines that are written for accessibility… a lot of them are written with the assumption that the Web is going to be this collection of inter-linked documents, pages.

What we’re seeing now is, more and more, we’re getting a mixture of documents and applications, and things that are halfway in between. And the Web was invented to be intrinsically accessible, and in a way we’re kind of slipping away from that. Are those new challenges as a result of missteps in the direction of the Web?

Interesting. I think, what started out as a document repository, so to speak, has evolved. And I think that’s something that may never have been envisioned, and therefore I think it’s very difficult, you know, as we’re building things now that are continuing to evolve the way that we use the Web and the way that the Web works, it’s very difficult to have and apply a set of guidelines that were conceived before any of the stuff that we’ve been thinking about was.

So I think there’s a bit of a disconnect, there; I’m not sure it’s really a misstep. I think that we can build a perfectly accessible, rich Web, but we’re still relying on tools and technology that were invented before the technologies that we’re trying to use and create rich web experiences with. So I think it’s just there’s a lag behind, not necessarily that there’s missteps, so to speak.

Just for example, ARIA, the new standard that’s being developed to bring accessibility to these rich web applications … are you optimistic about it making a big difference?

I am. I think in many cases it’s exactly what we need. In some cases, I don’t think we necessarily need ARIA. So, I am optimistic that we will get there; I’m just not optimistic it’s going to be any time really soon. The standards process is notoriously slow—and that’s not to say that the full specification of ARIA is going to be a slow-moving process. There’s a lot of people that are very interested in it. They want this to be something that happens, so it doesn’t surprise me if that is going to continue at a fairly rapid pace.

What I see as being the rate-determining step is how long it takes for that spec from being just a spec to being a spec that’s implemented and supported everywhere. And that’s what concerns me now, because I feel like there’s a lot of promise for ARIA, and people can get really excited about it, and we can start implementing some of it now.

But how long will it be until we don’t have this transitional phase where it’s partially supported and partially not? And how long will we need to be in a position where we’re catering for a non-ARIA world? And is it something that we’ll ever be able to forget? Will we ever be in a scenario where we can assume ARIA support will always be there, or are we still going to be working backwards in terms of our backwards compatibility?

In his talk yesterday, Jeff Croft was covering something that kind of is similar. He was talking about, in CSS, whether you should specify fonts with absolute pixel measurements, or with relative measurements. And he made the point that the pixel measurements, of course, that you cannot resize them in IE6.

What are your thoughts on that? At what point can we say, all right, we’re leaving that behind, and it’s up to you to use an up-to-date tool that will give you the best possible experience?

Yeah, I think it’s… there’s a bit of interplay between reality and—I don’t want to say fantasy, because I don’t necessarily think it’s fantasy, but it’s maybe our ideal view of what we think should be in the browser landscape. So, in my opinion, I’m still going to use relative units basically until IE6 disappears.

And I don’t know when that will be. I know one of the metrics that I’ve used to gauge whether or not I’m going to support a particular browser is when Microsoft basically says they’re not going to support that browser anymore, or whatever piece of technology—whether it’s a browser, or operating system, or whatever it is. When they stop support for it, that’s when I feel much more comfortable eliminating my support for it as well.

So, I’m … you know, the assumption that Jeff makes is that somebody that will require the capability to resize text will choose a better tool, to me that’s still a bit of a jump. I would like to believe that, I really do. I think we have a long way to go, though, in terms of end-user education, because people don’t… there’s a lot of people that use computers, sadly, that … they don’t necessarily know that they can change browsers. They use what’s on their computer and that’s the end of the story.

Now, having said that, we’re in a position now where, I mean, I have three children; they know more about computers at age four, seven, and nine, than probably I did when I was nineteen, just because we didn’t use them when I was younger. So, times are definitely changing. We still have a group of people that did not grow up with computers, and they’re not necessarily as comfortable. Is that our problem? That’s a really good question, and I’m not sure.

But I suppose in general, as developers, the more we can make our problem instead of the user’s problem, the better.

That’s generally the way that I approach things is I err on the side of caution. And a lot of our clients will talk about specific things, and I will be talking with them and saying, “You know, this is not necessarily an accessibility issue, it’s something else.” And they will come back to me and say, “We understand that it’s not strictly an accessibility issue, but our goal is to take into account all of our users and their needs, whatever they may be.”

And so if we want to provide, for example, some BrowseAloud functionality within their web site, then they will do that, because their goal is not necessarily to meet accessibility guidelines, but it’s to make sure that as many people can consume their content as possible. And so while I look at BrowseAloud and think this isn’t necessarily something that I would use on one of my web sites, they use it because they want to get their message to everyone. So that’s where I think there’s a bit of interplay there between whose problem it is, and who gets to solve it.

If you had fifteen minutes of attention from everyone building web sites today, what’s the one thing that you would like to teach them to improve the state of accessibility on the Web?

Oh, wow. If I had fifteen minutes… If I had fifteen minutes, I would want to find a way to have every web developer and designer experience what various people with disabilities would experience through whatever means, and in person if possible. Because that experience of seeing people and experiencing what shortcomings there are in our work when a person with a disability is using them … that’s a transformative experience, it really is.

So, that would really be what I would go for. If I only had fifteen minutes, it would be to take people through that, so they could experience that, and learn from that. And so they learn—I would want people to learn that keyboard interactivity is not for the sake of keyboard interactivity; it’s there so that people can use the sites in an application, and I think that’s what I would focus on, is the impact on people.

All right. I’m Kevin Yank. This has been Derek Featherstone. He blogs at boxofchocolates.ca [3]. Thanks very much.

Great. Thank you, Kevin.

Image credit: Jeff Croft [4]

[1] http://boxofchocolates.ca/
[2] http://sitepointstatic.com/audio/2008-09-27_derekfeatherstone.mp3
[3] http://boxofchocolates.ca/
[4] http://www.flickr.com/photos/jcroft/2886749135/