Posts Tagged ‘paul cotton’

Comic Update: Alone In The Pitch Black Dark

Monday, August 16th, 2010

Today’s comic features the chairs of the W3C HTML WG, Sam Ruby, Maciej Stachowiak and Paul Cotton as they and the Squirrel try to deal with the dangers of a cave monster in the dark. You’ll have to take my word for it, however, unless you follow the instructions on the comic to read the transcript. In a reversal of what is the norm, my sighted readers will have to take some extra effort to experience the joke; my visually impaired readers should be able to access the transcript like normal through the longdesc attribute on the comic.

Recently, these three personages made a Working Group decision about the fate of the longdesc attribute which you can read over here. The summary is this: the longdesc attribute, which is a method of serving detailed alternate text for complex images to visually impaired web users, is now obsolete and not a part of HTML5.

So much for backwards compatibility.

Almost a full year ago I addressed the issue of blind web users, encountering the topic on a personal level when I found that my commentary CAPTCHA at the time was challenging for a reader of mine because he was blind. A reader, at a web comic, who couldn’t even see the comics that my commentary accompany. I made a change to the site, setting up transcripts for every comic starting with that one, which can be accessed via either the longdesc attribute or an aria-describedby attribute, both attached to the comic’s image. I’ve been uneven at times in keeping the transcripts synchronized, but every comic since then has that alternate text so you don’t need operational eyes to be in on the joke.

I’m a bit confused to why it’s an issue for non-experts in the accessibility field to constantly be pushing against the presence of accessibility features that pre-exist HTML5 like longdesc. The most common arguments are that it’s largely unused. I know this is true. But that doesn’t seem like a reason to throw validator warnings for those sites that correctly use it for their users (like myself.)

Here’s the validator results for my comic page in HTML5 mode. Mind you, the page isn’t HTML5 yet (I’m really behind on a site redesign), but the one warning that shouldn’t be present is the last one: “The longdesc attribute on the img element is obsolete. Use a regular a element to link to the description.”

Excuse me?

Since when does a validator need to tell me how to design my site? The premise of a link on an a element is plausible (I’ve heard it a million times by now), but it seems to disregard the consequences for sighted users in some design experiences. In the case of the current comic page, I could wrap the comic in a link to the transcript, I suppose. That won’t work in the future design of the page due to interactions that I’ll be adding, however. Furthermore, for many sites, complicated images often have other functionality attached to a link around the image, like loading a larger version of the image or popping open a lightbox gallery. The only alternative at that point is add a separate link by putting an additional element on the page, aka, modify the design based on validation needs.

The fact is, most sighted users don’t want to click on an image description for alt text, because they can see the image. And non-sighted users have access to the accessibility features like longdesc. If a web developer is going to be providing alternative text for complex imagery to the point that he or she would actually create a description hyperlink, why wouldn’t this same person go an extra three inches and just use the longdesc attribute? The premise that a simple hyperlink is somehow more likely to be used is false: lazy people will be lazy no matter what.

I don’t expect this decision to somehow change. Not because I think it shouldn’t. I think it’s an incredibly stupid choice made to please punditry who largely don’t use any sort of alternate text for their sites whatsoever. I just think the issue’s been fought over for so long that those in the position to have the final say will gladly sit on the wrong decision just to move forward.

As a website owner who does make use of accessibility features for my actual blind users, I’ll take my validation error. The code was valid, it does work, and I don’t see any reason to clutter the visual design to implement a less elegant solution.