In the photo left to right: Me, Arve Bersvendsen, Lachlan Hunt*, Ian Hickson*, Anne van Kesteren*, and Geoffrey Sneddon*. Photo taken by Kai Hendry.
* Evil Cabal Member

Too much of our work happens over the internet (IRC, email, blogs, wikis, etc), for obvious reasons, and meeting in-person at least once a year gives you a chance to attach something more tangible to the experience. We each have our own “quirks mode” that is difficult to understand in a medium like email unless you’ve caught of the mannerisms, facial expressions, vocalizations, etc before hand.

A good overview of the “demoable” bits of HTML 5 (it is hard or too boring to demo lots of the parsing, dom consistency, error handling changes).

If you were following but dropped out of the <img> & @alt discussion going on in HTML 5 for the last several months – Ian Hickson has a new summary of all the numerous proposals, research, problems, spec changes, etc. Somehow two people publicly responded to Ian’s email in 5 minutes or less… I guess I’m slow because it took me probably thirty minutes to read the email, go back and research the various previous and current drafts, review all the cited links, etc.

In terms of proposals, there’s really only two core solutions to providing accessible text for <img> resources:

1. @alt is always required full stop.
2. @alt is available to use but not required.

(It has been suggested several times on public-html, forums, and blogs that HTML 5 removed the possibility to provide @alt text – this never never happened. @alt was made optional in early editor’s drafts, but not removed. Now that we have that cleared up…)

Every other proposal is a variant of these two… that is provide guidance and conformance language that determines that type of text that must be present under certain conditions. Often those conditions can’t be checked by a machine. This is where the fun starts.

HTML 4 choose solution #1 and whether you consider that choice successful or not depends on what your desired end-game was:

• Wide spread tool support for entering alternative text? Mostly good. Even Microsoft Word lets you enter @alt content.
• Wide spread use of @alt by authors in which the alternative content adequately describes the referring image? Not so good. Quite poor really. @alt is often missing altogether, present but empty, or simply repeats the image’s file name. Lame.

I can sympathize with the folks who feel that requiring @alt led to better tool support. Software engineers like requirements documents, test cases, etc. If the spec says “required, full stop.” it is easy enough to satisfy that condition.

At the same time I’m more of a “make it possible to do things with technology and step back” guy… provide a method of storing the alternative text but actually requiring it seems bizarre since we don’t have the appropriate artificial intelligence technology to check whether the alternative text describes the image resource to the various audiences. One problem with @alt is that has to describe the image as the author “sees” it as well as how end-users, spiders, and 3rd party services would like to interpret it as well.

Besides the legacy problems of @alt, there are front-end interface problems… such as it is particularly cumbersome to provide @alt text for say 25 images you just uploaded from your Nokia smart-phone or even an Apple iPhone. I don’t envision a lot of consumers patiently navigating through that experience.

Finally, there is a disconnect between what must be done now and what will be necessary when HTML 5 is fully deployed in the wild… which, in theory, is roughly a decade from now. Mobile web browsing is going to be wildly popular in 10 years and it will expose the UI problems even more than they are now. A solution that seems acceptable and fair today will be different than one suitable for ten years from now.

There’s no magic bullet for alternative text on the web. The solution requires a mechanism for software or, ideally, a human to describe an image through text and there are really several of these in HTML 5:

• @alt

@alt alone is not sufficient for all use cases. Supplying one of more of the following might be a way forward:

• @role
• @title
• <legend>
• <figure>

This the approach the current draft has taken, as Ian wrote in his email:

Are there cases where the image is lacking good alt text that wouldn’t be covered by one of the following?:

• title=”" attribute on the <img> itself
• <legend> of the <figure> that contains the <img>
• heading of the section that contains the <img>

We could say that for these “key content without alt text” cases, we have the alt=”" attribute omitted, but there must be at least one of the above, and the first of the above that is present must include sufficient information to orient the user.

I like the new draft a lot better — not just because of this approach, but the overall language (thanks to much feedback from public-html) is much cleaner. I look forward to seeing how the latest language is refined over the next few months.

I found this piece when earlier today Steven Frank linked to Gerry’s Star Wars Cantina Song rendition.

What I like best about Gerry’s work is that he takes his craft seriously but also seems to humbly accept it is a gimmick. The material he covers is all over the place, you should check out all 105 videos he has on YouTube, especially his performance and interview on Jimmy Kimmel’s show.

As a “Hey, this actually relates to HTML 5!” note, I’ll point out that Gerry’s content is an excellent example of why the <video> element is important for users who share their artistry online. Artist shouldn’t have to muddle the rights to their own content, which is exactly what is happening with every one of Gerry’s videos published on YouTube right now. On top of that, the video is delivered through a proprietary technology (Adobe Flash) because it is the best user experience available on the market.