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

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" 
/></a>
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.

Yours sincerely,
Leif Halvard Silli


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 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 Saturday, 14 August 2010 01:57:21 UTC