W3C home > Mailing lists > Public > public-html-a11y@w3.org > May 2011

Re: Moving longdesc forward

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 4 May 2011 13:20:35 +0200
To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
Cc: Laura Carlson <laura.lee.carlson@gmail.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <20110504132035770470.03d85459@xn--mlform-iua.no>
Benjamin Hawkes-Lewis, Wed, 4 May 2011 07:40:21 +0100:
> On Wed, May 4, 2011 at 2:26 AM, Leif Halvard Silli:

>> I concur with Richard:
>> 
>> ]] Change structured content to structured host language content.
>>   We don't want to use PDF to describe HTML or vice versa [[
>> 
>> Laura, perhaps you should take in this somewhere, if it isn't there?
  ...
> On the authoring side, if I have an HTML5 document and I link to an HTML
> document claiming conformance with HTML4, is that conforming?  What 
> if I link to an XHTML5 document? What if I link to a compound document
> format that includes the XHTML5 vocabulary?

May be a list of acceptable formats should be given rather than 
'structured host language content'. 

> Note that if we impose such a constraint we will render some existing 
> longdesc use non-conforming. Three of Laura's examples of @longdesc  
> in the wild use plain text for long descriptions.
> 
> http://www.d.umn.edu/~lcarlson/research/ld.html#fakoo

> http://www.d.umn.edu/~lcarlson/research/ld.html#securian

> http://www.d.umn.edu/~lcarlson/research/ld.html#buffalo


HTML5 is not about blessing existing content. I remind you that 
@longdesc all too often points to images. Also, remember that 
accessibility and validity are orthogonal: may be above example works, 
just like many invalid things do.

Purpose of longdesc is structured content. We undermine its legitimacy, 
IMHO, if we water it out.

Also, regarding rendering: if the UA can't expect a HTML - in the broad 
sense, how can it usefully present description in a new browsing 
context inside the same window? On an edge, we do not want that 
@longdesc becomes some kind of image presenter tool.

> Since a single URL can serve multiple formats, on the user agent side, we'd
> need to add a requirement that the URL be requested using an Accept header
> giving a higher quality value to the desired media types.

For @src of the IMG element, then HTML5 gives a very specific list. Is 
that list linked to use of an accept header?

http://dev.w3.org/html5/spec/embedded-content-1.html#the-img-element


>> Nevertheless, some comments on things that goes directly on my
>> own comments:
 ...
>>        <img src=october-sales-chart.png
>>             alt="October sales chart"
>>             longdesc=#chart-description>
>>        <details>
>>            <summary>Description</summary>
>>            <p id=chart-description>Bar Chart showing sales for October.
>>            There are 6 salespersons. Maria is highest with 349 
>> units. Frances
>>            is next with 301. Then comes Juan with 256, Sue with 250, 
>> Li with
>>            200 and Max with 195. The primary use of the chart is to show
>>            leaders, so the description is in sales order.</p>
>>        </details>
>> 
>> Comment: It is seems problematic to mix <details> into this.
> 
> Problematic how exactly? (Wondering if this suggests something
> else that needs specifying.)
> 
>> Not sure we win anything by doing so.
> 
> Can you suggest an alternative concise example that illustrates same-page
> @longdesc? :)

If I placed it on same page, I would probably have hidden it 
completely, in one way or another. For example, one could keep the 
description inside the @longdesc itself, as a data URI.
-- 
leif halvard silli
Received on Wednesday, 4 May 2011 11:21:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:42:38 GMT