Re: Letter to the Team Contact - ISSUE-30.

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 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].

[1] http://lists.w3.org/Archives/Public/public-html/2010Aug/0148
[2] http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0043
[3] http://lists.w3.org/Archives/Public/public-html-a11y/2010Aug/0039
[4] http://lists.w3.org/Archives/Public/public-html/2010Aug/0131
[5] http://lists.w3.org/Archives/Public/public-html/2010Aug/0144

With regards,
Leif Halvard Silli


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:
> 
http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/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.
> 
> Concerns
> --------
> 
> 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 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 
> validator.nu 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.
> 
> [1] http://www.w3.org/TR/html4/struct/objects.html#adef-longdesc-IMG
> 
> This letter of concern is mostly a summary of points I have made in the 
> following letters:
> 
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0117
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0119
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0128
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0129
> http://lists.w3.org/Archives/Public/public-html/2010Aug/0140
> 
> With regards,
> Leif Halvard Silli
> HTML WG Invited Expert
>

Received on Friday, 13 August 2010 20:05:05 UTC