W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2010

Re: Working Group Decision on ISSUE-30 longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Thu, 12 Aug 2010 05:10:53 +0200
To: Sam Ruby <rubys@intertwingly.net>
Cc: HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20100812051053505216.1244f088@xn--mlform-iua.no>
Sam Ruby, Wed, 11 Aug 2010 21:22:03 -0400:
> On 08/11/2010 07:56 PM, Leif Halvard Silli wrote:
>> Sam Ruby, Wed, 11 Aug 2010 09:16:05 -0400:
>>> Here is the decision. It has been drafted in HTML format to aid 
>>> readability.
>> The decision contradicts itself on an important point. Consider:
>> 	]] alternatives exists (explicit links, aria-describedby,
>> 	   figure captions) [[
>> Against:
>> 	]] The strongest argument against inclusion was the lack of use
>> 	   cases that clearly and directly support this specific feature
>> 	   of the language [[
>> Question: If it is uncontested that "alternatives exists", then how can
>> it be contested that use cases exists? What exactly do you mean here?
> Key phrase: "that clearly and directly support this specific feature 
> of the language"
> There certainly are use cases for providing textual descriptions.  

This is much too unprecise. Longdesc is not for "providing textual 
descriptions". It is for providing an _longer alternative_ to an 
existing textual description.

In contrast, there is no guarantee that aria-describedby provides the 
user with a long variant of the existing short description. An 
aria-describedby attribute can contain references to several fragments 
of a page - no one knows exactly what to expect from it. Same with a 
general link - its relationship is not always clear. When it comes to 
<figure>, then I don't quite understand how it can be associated with 

> There are multiple ways to provide such.  None of the use cases 
> described clearly and specifically required the addition of a 
> longdesc attribute to the language.

Is longdesc anything _but_ a link of long description type for the IMG 
elment and frames? Are you willing to restate the above as follows: 
"None of the use cases described clearly and specifically required the 
addition of *a* longdesc *link type* to the language" ?? (I hope not.)

The lack of longdesc link that can be attached directly to the IMG, 
means that e.g. in a collection of images, the ones *with* a long 
description will have to be marked up in a way different from those 
without a long description.

Mind you: rel="longdesc" is not part or HTML5. Thus, that option is not 
amongst the "multiple ways", yet. Are you rejecting longdesc because it 
hypothetically can be solved in a different way?

>> The decision further claims - under the heading "Functions" - that:
>> 	]] It was stated that without this attribute, there is no current
>> 	   way to reference a longer description of an images without
>> 	   including the content in the main flow of a page.
>> 		... snip ...
>> 	   While the former is uncontested, ... snip ... [[
>> I'm sorry, but this seems rather weasel worded. Or, to put it clearly:
>> This *is* contested! One can simply do<a href="longdesc"><img src=*
>> alt=*></a>  - no need to include any content in the main flow of the
>> page. Ian has also, correctly, once mentioned that<object>  is an
>> alternative - such a thing does not add anything to the main flow of
>> the page.
>> And, by the way, in which objection was the above stated? Did anyone
>> say "strawman"?
> http://www.w3.org/2002/09/wbs/40318/issue-30-objection-poll/results#xkeepnew
> Charles McCathieNevile point 2.

OK. But my critic were on you, for accepting that that claim is 

Secondly, you are - again - disappointingly inaccurate: Charles 
statement was an objection towards the null change proposal, about 
which he said "This proposal fails to adequately address two 
functionalities of the longdesc attribute." And then he cited "A method 
to reference a longer description of an image, without including the 
content in the main flow of a page" as one of those two 
functionalities. Where in this did Charles state what you attribute to 

>> The most important problem of the decision document is that it lacks a
>> focus on semantics. One of the objectors, Lachlan, suggested early on
>> that one could do something like this instead of using @longdesc:
>> 	<a href=* rel=longdesc href=URL><img src=* alt=*></a>
>> And Lachlan's proposal was spot on with regards to the *semantics* of
>> @longdesc. It is the best alternative to @longdesc, so far. And, to be
>> honest, I am considering accepting this decision, and instead focus on
>> registering rel="longdesc" in the link type registry. The only problem
>> I have, when I am considering the rel="longdesc" solution, is that your
>> decision uses so much energy in stating that there is no use case, that
>> I really wonder if if rel="longdesc" would have your support. Or,
>> perhaps someone would point to your longdesc decision and reject
>> rel="longdesc" on that ground. (Therefore, please clarify the
>> contradiction I pointed to above.)
>> Under the Functions heading, the decision also states:
>> 	   ]] It was further stated that user agents could very well open
>>            this content in a new window.   snip  As to the latter,
>> this
>> 	      was expressed in a hypothetical manner, and therefore was
>>            not given much weight. [[
>> Since this refers to my objection: that was a very bad willed reading
>> of what I said! Yes, I said "could very well open in new window". But
>> e.g. one paragraph above I said: ]] @longdesc usually works like an<a>
>> element with a target="_blanK". (iCab, Jaws and others) [[.
>> Otherwise, you could just have read the e-mail that was linked to that
>> statement, in which I explained how iCab works. But the crucial thing
>> is not that it is implemented exactly like that (even though I consider
>> such implementations a fine interpretation of the semantics!), but - as
>> Gez said in his objection - the alternatives (when we look away from -
>> in some fashion - using explicit links) "doesn't allow the user to
>> control how they interact with the longer description".
> An attempt was made to determine what use cases require longdesc. 
> Apparently we agree that "opening in a separate window" is not one of 
> them.

From "expressed in hypothetical manner" to "we agree"? 

You complain about lack of definition of "successful". But where is 
your definition of "require"? 

Do you see any good in longdesc at all? Are you able to see what it 
was/is meant to be? Can you describe how to do it in another way? Yes, 
we can remove longdesc. But that requires that we replace it with 
something equivalent. If - of course- we are able to spot a use case 
for it. If there is no use case, then there really are no other way to 
do it either - talking about alternatives becomes meaningless.

Gez describes it the best way: Longdesc gives the user a choice: he/she 
can read the alt text. And if he/she wises, the user can open the long 
description as well. ARIA does not provide this, says Gez. <object> 
also doesn't, I say. Object gives you the long description at once. 
Well, it is always possible to place a short description as fallback of 
OBJECT, and then have a link to somewhere else, inside the <object>. 
However, HTML5 is geared towards IMG. 

>> Finally, some notes which goes on the quality of your document:
>> Under the heading "Implementations" you lower the credibility of the
>> decision arguments, with several inaccurate statements:
>> 	]] It was stated that the longdesc feature was implemented multiple
>> times successfully. Cited were Opera, Firefox (which apparently
>> subsequently removed this feature), Dreamweaver, and XStandard. Newer
>> versions of IE may produce a tooltip based on this information under
>> certain circumstances. No criteria was provided for the adjective
>> "successfully". [[
>> However, a simple comparison with the actual objections reveals the
>> following:
>> 	1: Firefox was never cited as a successful implementation. The only
>> one who mentioned it, was Jon, who mentioned it as an *unsuccessful*
>> implementation. He did, however, not say in which version of Firefox
>> there had been such support. And he also did not state by which
>> criteria it was unsuccessful: Was it the fact that their implementation
>> was so "poor"? Or was it the fact (?) that it received so little usage?
>> Or was it the combination of those to factors? And btw, how was he able
>> to *measure* that it "received so little usage"?
>> 	    It is another thing that Firefox has *add-ons* which provide this
>> feature (last updated in January 2010). Patrick Lauke's earliest
>> version of his longdesc add-on is from March 2005, which is before
>> Firefox 1.5 was released. Thus I question whether it is true that
>> specifically Firefox has ever implemented @longdesc - perhaps Mozilla
>> has, but not Firefox.
>> 	2. Despite stated in the objections, you have overlooked that Jaws was
>> cited.
>> 	3. Despite stated in the objections, you have overlooked that iCab was
>> cited.
>> 	4. I am unable to see that any objectors have commented on the tooltip
>> that newer versions of IE is able to produce. Compared with the many
>> times the decision document applies a quite literal and
>> not-exactly-good-will reading of the objections, I find it remarkable
>> that you, on your own initiative, brings in how Internet Explorer works.
>> 	5. It would have been more relevant to mention that Internet Explorer
>> (even in old versions, I believe) when used together with Jaws (a
>> combination which Charles mention in his objection) makes longdesc URLs
>> accessible to the user.
> http://www.w3.org/html/wg/wiki/ChangeProposals/longdesc
> The rationale consists of two paragraphs.  The first contains some 
> background context.  The second makes two points, one concerning 
> implementations, and one concerning benefits.  Neither are 
> substantiated in the the change proposal itself.

You demand perfection from the arguments. But you yourself serve us a 
document which states that someone has claimed that Firefox had a 
successful implementation. Which no one has claimed.

> Efforts were made to identify what implementations could have been 
> referenced by this rationale.  Eventually, trying to determine 
> whether or not IE supported longdesc lead to the following page:
> http://msdn.microsoft.com/en-us/library/ms534132%28VS.85%29.aspx

And have you tested whether that holds true?

When IE8 came out, its claimed longdesc support created a puzzle. If 
you look at the work blog of Steve, you will find there, somewhere, a 
post about his investigation of in what way IE8 does (not) support 
longdesc. I guess there is a reason for why no one has brought IE to 
the table as the successful implementation. IE also has unsuccessful 
implementations of a whole range of other things.

> You are correct that iCab and Jaws should have been cited.
> The existence of addons wasn't mentioned in any objection or change 
> proposal.

Why weren't efforts made mention in the decision? Why did you not 
investigate what Jon said about Firefox?

>> Sloppy errors like that undermines the trust in the rest of your
>> arguments.
>> As to to the lack of ]] criteria  for the adjective "successfully" [[.
>> This does not feel like 100% honest critic.  It is pretty obvious that
>> what Charles meant to say in his proposal, was that it is easy to
>> implement @longdesc - it is not a complicated feature: It is simple to
>> read what HTML4 says about longdesc, and then to implement it. Longdesc
>> is even defined in the DOM specifications. Btw, I have previously asked
>> iCab's developer, who claimed that longdesc is very simple to add.
> It is neither obvious nor generally agreed upon that longdesc has 
> been deployed successfully.

The string "deploy" does not appear a single time in the decision 
document. Nor amongst the objections. Nor in Charles proposal. Charles 
talked about "implemented multiple times successfully". It is not clear 
to me how "deploy" is relevant (but that might because I don't fully 
understand what it means). 

In principle, how it should best be implemented, can be discussed. The 
implementations I have seen implements it in the chrome and/or in 
contextual menus. But authors may also use CSS to make readers aware of 
it - plus that there is a DOM interface for it.

>> Finally, you cite as uncontested that ]]more work is needed to make
>> longdesc useful [[. But of course! The editor has made it obsolete!
> Improving (as opposed to replacing) was a point that Laura repeatedly 
> made.  That point had nothing to do with the editor.
> - Sam Ruby

The decision document clearly cites "more work is needed" as something 
which opposes inclusion of longdesc. However, pointing out that more 
work is needed is about being honest. It would be dishonest to say that 
there is no problem.
 The more work that is needed would primarily fall on the editor and on 
conformance checker developers.

As long as @longdesc is obsolete, we cannot even implement the lowest 
hanging fruit: URL validation, which is something Validator.nu 
implements for all other attributes which take a URL. It seems to be 
uncontested that URL validation is one of the thing that longdesc needs 
the most. (But for some reason, you chose to not say the same thing.)

I don't understand your point about the editor. My point was only that 
as long as it is obsolete, the feature is simply parked, and nothing to 
improve it happens.

Finally, I find the point that uses are not aware of this feature as 
pretty moot: Users don't care how thing is implemented. We don't need 
that users know that there is something called @longdesc.
leif halvard silli
Received on Thursday, 12 August 2010 03:11:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:42 UTC