W3C home > Mailing lists > Public > public-html@w3.org > February 2008

RE: longdesc Re: Clarification of rational for deprecation...

From: <stephane.deschamps@orange-ftgroup.com>
Date: Wed, 6 Feb 2008 11:55:55 +0100
To: "'Charles McCathieNevile'" <chaals@opera.com>
Cc: "'HTMLWG'" <public-html@w3.org>
Message-ID: <005f01c868ae$d93b75d0$0b12b30a@stquentiny.francetelecom.fr>


-----Message d'origine-----
De : Charles McCathieNevile

Charles said music to mine ears, among which:

> So while some things (especially while they were not well supported) have
resulted in abuse, I don't think it follows that we should therefore assume
there is no baby in the bath, and just tip it all out - especially, if the
actual cost of the abuse is low, and in the longdesc case I claim that the
real cost of abuse compared to the benefit of good use is vanishingly small
even when most usage is incorrect.

True, we *should* keep the mechanism.

> But I draw a different conclusion on what that actually means to users.  
> Most users don't care about longdesc, they look at the picture, and don't
even know if it has a long description, so the longdesc attribute value has
exactly zero relevance to them. Of the few users who rely on it, or benefit
substantially from it (who are currently primarily screen reader users -
along with iCab users they are the only people with ready access to tthe
functionality anyway) most are in a position where something that works 20%
of the time is better than something that doesn't work at all, since they do
not get an alternative.

> In conclusion, I think the rationale for deprecating the attribute fails
to take appropraite account of how its accessibility use case plays out in
the real world, and of what it offers people. It may be appropriate to
develop a new and hopefully better alternative to longdesc alongside the
current HTML 4 version, but I have not seen any proposal that actually meets
the same needs. I therefore think we should not deprecate the attribute.

(sorry for the bad-bad-bad quoting, my email client is not up to par)

I've been pondering for a little time now, and read
http://esw.w3.org/topic/HTML/LongdescRetention

In short:
1. pro: longdesc, when used, and when used properly, is useful
2. con: longdesc requires another HTTP request to usually another resource
3. con: statistics of ill-use or no use are high
4. pro: Denis Boudreau's original argument that it is not because
semantic-oriented practices didn't occur ten years ago that h1-h6 tags were
dropped, and I agree with him. You've just added to this pro.
5. assistive technologies have mechanisms to read the mandatory @alt text as
well as indicate the presence of @longdesc and propose a way to read it

In the wiki, someone suggested using <div role="longdesc">. I'm not a big
fan of it as it complicates CSS implementation (off the top of my head, feel
free to correct me), although I see the simplicity of adding @role to any
element and making HTML more open to further role-naming.

What about simply introducing an optional <longdesc> container for inline
and block-level content as a child of <figure>:

<figure>
  <img src="rintintin.jpg">
  <legend>The almighty RinTinTin</legend>
  <longdesc>
    <p>This is a black-and-white photo of Rintintin, a german shepherd
featured in a TV sereies somewhere in the sixties</p>
    <p>It shows the dog, sitting, its tongue out of its mouth. Its eyes say
"I love you". Silly dog, really.</p>
  </longdesc>
</figure>

The way I see it, when <legend> is implemented, assistive technologies may
end up using their @alt-reading mechanism and map it to figure>img+legend as
well as <img>@alt. (please forgive my pseudo-notation)

Similarly, they could translate <img>@longdesc and also map it to
figure>img+longdesc.

The spec could define <longdesc> as display:none by default, and we'd be
free to either display it through our CSS if we deem our additional content
worth displaying or let assistive technologies do their job if our content
is a longdesc strictly speaking.

Also, it would be simpler to implement in industrial CMS's, who are
notoriously bad at providing easy longdesc mechanisms.

My apologies if this has been proposed already. My idea is to rely on
existing, *working* mechanisms and to not leave people on the side of the
road, while trying to propose a simple way of retaining the notion of
longdesc.
  

--
Best regards,
Stéphane Deschamps
  Web HCI expert
  orange / france telecom group 



*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************
Received on Wednesday, 6 February 2008 10:56:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:12 GMT