Status of this document:

Per March the 2nd 2011: The Chairs today decided to look at ISSUE-30 once more, see message in public-html. Because of this I was asked by co-chair Sam Ruby to, at least for the time being, reconsider my Formal Objection. The current status is therefor that I have withdrawn my formal objection.

Letter of Appeal to the W3 Director via the Team Contact

Formal Objection to the Decision on ISSUE-30 (@longdesc)

by Leif Halvard Silli. Updated 23rd of August 2010. Post Scriptum added 23rd of November 2010.

Background info

When the co-chairs published the HTML Working Group Decision on ISSUE-30 – the longdesc attribute, I immediately raised som questions in the public-html mailinglist. The dialog I had with co-chair Sam and co-chair Maciej, in the end caused me to write this an Appeal to the Director – via the Team Contact, Mike Smith.

The Appeal was changed into a Formal Objection on the 23rd of August, as this seemed like a more useful form of objection.

Appeal Formal Objection

The following are direct quotes from the Appeal Formal Objection - except a few clearly marked spelling error corrections, and also I changed the wording from «Appeal» to «Formal Objection», to reflect the change of status of this document.

Leif Halvard Silli, Fri, 13 Aug 2010 15:23:38 +0200:

Mike Smith,

I write to you as Team Contact, about my concerns with regard to the HTMLwg Decision on ISSUE-30:
[link to the ISSUE-30 Decision]
A CC goes out to the HTMLwg co-chairs, to public-html@ and www-archive@

My time is limited, so if you feel that some issues are under-documented, then please tell me and allow me to follow up.


1) Errors in the decision document

The are many errors in the decision document - some of which the chairs have already admitted to. The document fails to make an accurate summary of many many things. Examples: Firefox is listed as a "successful" implementation of @longdesc, despite that Jon's objection state the opposite. And a few successful implementations that _are_ listed in the objections, are omitted as such examples in the decision document: Jaws, iCab. And Charles's presentation of @longdesc (in his objection to the zero-change proposal), is presented as if he says that @longdesc is the only way to technically link to a long description. These and a few other errors (which probably are just errors and not conscious errors) are easy to check simply by reading the relevant objections and proposals, undermines the trust in the decision as a whole.

2) Criteria for use of certain words

The decision demands things of the change proposers and objectors, which the decision fails to live up to itself. One of those demands are very specific criteria for the use of certain words. Example: the decision (unduly, in my view) complains about lack of definition of «the adjective "successfully"» (which is a an adverb, btw ...).

However, the decision itself operates with several words for which it provides no criteria. Examples: 'use case' and 'require'. It is entirely unclear what kind of 'use case' the document wants, though, for the most part, the document seems to look for technical reasons to have @longdesc.

To my mind HTML4 describes a use case: [1] "a link to a long description of the image. This description should supplement the short description provided using the alt attribute.". There are no links in HTML4 or HTML5 other than @longdesc that have this semantic. As such it @longdesc is required. (The proposal to keep @longdesc duly links to HTML4, and so the decision have every reason to discuss what HTML4 says - but fails to do so.)

3) Concerns not being duly considered

Example: Longdesc link rot with invalid URLs was cited as a problem both in the objections, in the zero-change proposal _and_ in the decision document. In my objection, I pointed out that this - in a way - automatically becomes solved as soon as @longdesec is made valid: by making @longdesc un-obsolete, HTML5 conformance checkers must - obviously - start to conformance check the @longdesc URL. (Explanation: in the HTML4 validator, no URL validity checking is performed whatsoever, whereas does check URLs, as long as the attribute isn't obsolete.)

I filed a bug about this, to make sure that conformance checkers would do this, and the link to the bug is in my objection.

However, not a single time does the decision document that it has considered this simple and obvious argument. Instead, the decision document states it to be "uncontested" that "more work is needed to make longdesc useful". However such a general statement is hardly relevant when the required work, at the most basic level, simply involves moving @longdesc from the list of obsolete attributes to the list of valid attributes.

4) No evaluation of @longdesc from a semantic angle

This goes back to my 'use case' critique under 2) above. In the subsequent debate, I took up an idea that I picked up from Lachlan. Namely that rel="londesc" (<a rel="longdesc" href="*"><img alt="short description" src="*"></a>) many times could be used as a replacement for the @longdesc attribute. (The exception being when there is already a link on the IMG. Another exception is on iframe elements, which HTML4 also allows: the <a> element is not allowed to be a wrapper around an iframe element.) The response has been that rel="longdesc" is worth looking into. If we see @longdesc as shorthand for the - yet undefined - rel="longdesc" micro format, then should be obvious that the issue is about semantics.

(In my objection, I compare @longdesc with a special kind of link, although I fail to mention the rel="longdesc" parallel.)

However, the only time the decision uses the string "semantic" is when it states the following: "A number of use cases for semantically rich, structured descriptions of images were provided, however those use cases are abstract and don't directly and specifically require the support of a longdesc attribute".

By this definition, then even what HTML4 says about @longdesc is abstract!

Apart from the situations when <img> already has a link as well as the <iframe> use case (see above), then it is probably impossible to find concrete examples of use cases when it is _technically_ impossible to solve the problem unless the language includes @longdesc. However, _semantically_ the language currently has no other method than @longdesc for solving the issue. But I look in vain for a discussion of this problem in the decision document.


This letter of concern is mostly a summary of points I have made in the following letters:

With regards,
Leif Halvard Silli
HTML WG Invited Expert

Leif Halvard Silli, Fri, 13 Aug 2010 22:04:11 +0200:

Mike Smith,

In addition to replacing 'link rot' with 'invalid URL' [1], I would like to also add a fifth concern:

5) Undue stepping outside the arguments found in the Change Proposals and the Objections.

In a follow-up, Maciej stated: [2]

]] We specifically do *not* attempt to apply any considerations that were not raised in the Working Group. [[.

However, that is exactly what the Decision does.

Example: The Decision goes into detail about what Microsoft's documentation says about how Internet Explorer 8.0 interacts with @longdesc. A subsequent statement by Sam hints that the Microsoft information was added in order to show that @longdesc does not have "widespread interoperable implementation". [3] At any rate, the information does not come across as an positive argument for @longdesc.

When a Decision takes in information - evidence - which does not stem from [2] ]]the contents of the Change Proposals and objections themselves[[, the objectors and proposers themselves are of course unable to respond (without appealing the decision). As a matter of fact, many working group members are aware of how IE8 works. And from another angle, exactly IE - in combination with screen reader software - has excellent longdesc support. Thus it would have been a highly relevant piece of information for the objectors and proposers to comment.

Such self-investigation also triggers another question: if the Co-Chairs are able to investigate a point which has not been mentioned by the proposers and the objectors, then why aren't they also able to investigate issues that are specifically mentioned by the proposers and objectors, but which the Decision claims to be under-documented? (Such as the criteria for the word "successfully".) As is, it is possible to speculate that the co-chairs have investigated issues that looked to support their view, but failed to investigate issues that could have lead to another Decision.

I am not principally against that co-chairs investigate things on their own and use these findings in a Decision document. In fact, I would prefer that the co-chairs to be active would actively seek the best Decision. However, since the co-chairs claim to follow the laid-back, un-active policy described by Maciej, then - whenever co-chairs actually break this code of conduct - it seems fair to expect their investigation to have been as broad, even an fair as a Decision document demands.

In this case, however, the co-chairs took the Decision in the opposite direction: they added the co-chair investigation results about IE8, but did to not mention the user agents which the objectors and proposers mentioned, such as Jaws and iCab. (Regarding the omissions, see my first point of concern - "Errors in the decision document".)

A fair investigation would have shown what the subsequent debate has shown: Despite its shortcomings, Internet Explorer is a much better argument *for* @longdesc than the Decision makes it seem. And @longdesc is supported by more tools and user agents than the objectors and proposers remembered to mention. E.g. see the messages from Roy [4] and Denis [5].


With regards,
Leif Halvard Silli

Leif Halvard Silli, Sat, 14 Aug 2010 03:56:41 +0200:

Mike, I believe I could add several more points of concern, but let me at least finish off with a sixth point:

6) Summarily technical evaluation

The section 'Function' evaluates some technical arguments pro et contra @longdesc. However, the technical features that are unique to @longdesc are not credibly evaluated - if evaluated at all. Examples:

* HTML4 - to which there is a link in Charles' Change Prop - says that a longdesc link must be accessible also when an image is wrapped inside an anchor element. This specific requirement/feature/advantage is not discussed anywhere in the Decision.

* An effect of the above HTML4 requirement in combination with the discrete way that @longdesc has been implemented in the user agents which support it, is that it is possible to add a longdesc link without attracting attention from users for which such a thing would only be a distraction. This is taken up by Laura, who points out in her objection that @longdesc can be used when e.g. "the marketing department due to aesthetic considerations" does not accept placing a normal link on the IMG. However, her concrete example is not discussed by the Decision. The only comment in the Decision which perhaps - it is difficult to grok - speaks to her concern is that ]]no evidence was provided that this is a necessary or even desirable characteristic; in fact arguments were presented by others to the contrary[[.

* Gez pointed out in his objection that a longdesc link gives the reader a choice - it "allow the user to control how they interact with the longer description". In my words: it is a pull technology. Whereas for ARIA, then - in the words of Gez - «it's just forced on the user as a string of text.» Given the tone of the Decision, it is tempting to assume that Gez' arguments would have been rushed to the side with the argument that no evidence has been provided for the claim that the user needs such a choice ... However, this is just pure speculation since Gez' argumentation is not discussed anywhere in the Decision.

* Having investigated how the opening of longdesc links are implemented in a number of user agents, I myself described in my objection how longdesc links are typically opened in a new window. To put it differently, they typically work like the following micro format would work:

<a target="_blank" href="url" rel="longdesc">
    <img alt="short desc" />

This behavior has (such is at least my claim) the advantage that it allows the user to quickly jump to the long description and back to the originating page again without loosing the context.

I described this somewhat summarily in my objection. But I pointed to a message in public-html where I described it in more detail. However, because I - in my objection - at one place used the wording "could very well open in new window", the authors of the Decision document found it possible to rush my arguments to the side with following words: "As to the latter, this was expressed in a hypothetical manner, and therefore was not given much weight."

When the co-chairs are able to, on their own initiative, look up what the Microsoft web site say about Internet Explorer and @longdesc, then it is "interesting" to see that they are unable to properly read - and follow links - in the objections.

I believe this concludes my Appeal Formal Objection .

Yours sincerely,
Leif Halvard Silli

Post Scriptum

Additions that was made after the bulk of this documented had been written.

The longdesc research page by Laura Carlson

This section was added on the 23rd of November 2010.

Link to the research page:

After the WG decision was announced, Invited Expert Laura Carlson started a project to document longdesc implementations — in a wider sense of «implementation».

The page has been made well known in the community that care for longdesc and Laura has thus been able to update it with lots of relevant information, making it the probably best and most complete documentation of longdesc implementations available.

By reading that page, one will be able to find – amongst other things – links to the following:

– and more.

End of document