Joe Clark

In: Interviews

By Craig Saila

Published on October 29, 2003

Accessibility in general
Techniques
Captioning

Accessibility in general

Digital Web: “Accessibility” is now part of the Web development community’s lingua franca. However, it’s often used as shorthand to mean making a site function for blind people. How would you define it, in the Web development context?

Joe Clark: I use the same definition of accessibility everywhere: accommodating features a person cannot change or cannot change easily.

The issue in Web accessibility is the fact that blind and visually-impaired people need the single biggest boost to achieve equivalence, since the real-world Web is a visual medium. (HTML itself does not assume a visual display, but since most people who use the Web can see and all their software is set up to provide a visual display, that’s how the Web is actually used. Even the inventor of the Web, Tim Berners-Lee, is a sighted person.) Because blind Web surfers have the biggest single need, there has been an equation of accessibility with blindness.

The problem is that other disability groups may be difficult to accommodate, as with cognitive or learning disabilities. Even mobility impairment can be a bit of a bother to accommodate on sites with a lot of links.

Digital Web: Have you seen an improvement in the accessibility of mainstream Web sites since governments started legislating requirements?

JC: In a word, no, and the premise is incorrect. A case could be made that in Australia and the U.K. there is something resembling a government (or let’s say “legal”) requirement that all sites be accessible. In the U.S. and Canada, at best, the requirements pertain to government’s own sites, and federal government sites at that. (Actually, now that I think of it, the province of Ontario has to meet Web-accessibility standards under the Ontarians with Disabilities Act.)

In any event, accessibility is almost as poorly-known now as it was 2.5 years ago when I started work on my book. That’s because most “Web” developers aren’t making Web sites at all, since they don’t have a clue what valid HTML and CSS means. If you’re not writing valid HTML, you are not making actual Web sites. You may be creating something else, and “Web” browsers may be able to read your document, but you’re not really engaged in Web development.

Since accessibility is a subset of Web standards, “Web” developers’ near-total ignorance of standards also implies a near-total ignorance of accessibility.

Even if you set aside the need for valid code, it is ridiculously easy to find non-government sites that flunk even the simplest and most canonical requirements of the Web Content Accessibility Guidelines, like using alt texts for images. Just check your morning bookmarks. Do any of them at all comply with the WCAG? Probably the only ones that do are Weblogs concerned with standards compliance and accessibility, and how many people read those compared to fan pages for Joe Millionaire?

Techniques

Digital Web: There’s been some debate, in a few Web design community groups, about the use of skip-navigation links. Although no one debates their usefulness, questions revolve around whether or when to make them visible. What’s your opinion?

JC: Gotta be visible. Blind people aren’t the only users of skip-navigation links.

You have to understand why they’re necessary in the first place: Lengthy lists of links are tedious to wade through. Sighted people with good mobility can just ignore them (essentially a banner-blindness phenomenon). A blind person using a screen reader must experience the links one after another, which is rather inconvenient. They’ve got better things to do.

But a mobility-impaired person—as in the case of someone who uses a limited switch mechanism to operate a computer—probably will not be using a mouse and will be stuck tabbing from link to link. If anything, this is more frustrating, since you can see where you want to go and you have to inch through an obstacle course of links to get there.

The real solution is to reduce the number of links. Rethink what you really need. Or put them on the right-hand side of the page (and/or at the end of the HTML). If you’re stuck with a legacy layout or similar, you do in fact have to include skip links and they do in fact have to be visible—if there are so many links that they become onerous. It is a judgement call.

All these are, however, hacks, which leave one feeling vaguely unclean. Nonetheless, we need better user testing of techniques like these. I am not convinced my suggested methods are actually as usable as I think they are.

Digital Web: What about the accesskey and tabindex attributes. Are they viable alternatives for skip-navigation?

JC: Not really. Support is poor, they’re badly misunderstood, there are too many conflicts with browsers and operating systems, and it is virtually impossible even to make clear to the visitor what the accesskeys are.

Now, tabindex is the marginally better of the two. You can use that attribute to cause the tabbing cursor to move to points of likely interest first, then everything else later. Quite possibly you wouldn’t need this feature, though, with a re-thought layout.

Digital Web: Another thread emerging in the community is how to make a dynamic menu accessible. In your superb book, Building Accessible Websites, you suggest —hesitantly it seems—a way. Will you summarize it here?

JC: You can use any standards-compliant method, but you’ll probably hack together a noncompliant method even though I just suggested otherwise. My solution is to make the top entry in each menu—the title of each menu, in effect—a link to a separate page that includes all the links found in the menu. In a worst-case scenario, you can activate the head of the menu to read another page that links to everything in the submenus.

This too may not be such a hot method. Anyway, I rarely see a need for menus of this sort. They’re too complicated to develop and certainly too hard to use, even for nondisabled people.

Captioning

Digital Web: One of the other “forgotten” areas of online accessibility, but a passion of yours, is captioning. Does AOL’s recent decision to begin captioning some of its videos herald a change?

JC: Well, I have not gotten Tom Wlodkowski of AOL on the phone to talk about it, but my impression is that AOL is recapitulating the history of captioning on broadcast TV—do it late in the evolution of the medium, on only a portion of available programming, and through the use of a complicated closed-captioning method. You’ll need a particular player to watch the captions, which you must turn on, and which will be compromised by the limitations of players’ own captioning.

The complicating factor is that all of the above might actually be the most practical and defensible approach at this stage. There are so many parts of online captioning that either don’t work or work badly that just getting it to work at all is an achievement.

I had a project with CBC last year (it’s still online) that simply decoded TV closed captions. Dirt cheap, anyone could watch, technically simple. Of course, there’s still the problem of picking and choosing which programming will be captioned. For any broadcast program with TV captions, you can immediately reuse them, which is something nobody is doing.

Digital Web: Are these technology issues part of the reason why online captioning has taken so long?

JC: Yes, it’s partly technological, since the three main video players—which by no means are the only players out there—have slightly-incompatible ways of including captions with video. You can’t even get reliable left, center, and right alignment in online captions. The fonts are shockingly bad.

“Authoring tools” are terrible; there is almost no software that can create closed captions for media players. And of course there is no training. TV captioning is bad enough, and this stuff is generally worse.

Also, think of what adding captions to video means for mom-’n’-pop Web sites. It’s quite simple to post video online. It’s way simpler than getting that same chunk of video on TV. The files may be large and the bandwidth costs may be high, but at essence it’s a drag-and-drop process. Now if someone comes along and tells you that you should spend four to eight times the program length beavering away on captioning it, or pay someone to do it, and it’s not legally required and there are all sorts of technical incompatibilities, would you jump at the chance to do it? Probably not.

I’m involved with a project that is investigating “best practices in online captioning,” and by April 2004 I should have a very useful report on the topic.

And then there’s the problem of audio description. You need to add narration to many kinds of video so that blind people can follow along. But almost no one does it, and the accessibility problems are worse there, since the player interfaces are poorly accessible in many cases.

Digital Web: Along with multimedia, what are some of the other notable accessibility hurdles encountered online?

JC: Navigation is important, but the single biggest issue is prodding Web developers into learning how to make standards-compliant sites. They’ve quite simply been doing it wrong all along. If you make a valid site, you get most of Web Content Accessibility Guidelines Priority 1 requirements for free.

Related Topics: Accessibility, Usability, Web Guru