Re: Moving longdesc forward

Benjamin Hawkes-Lewis, Wed, 4 May 2011 01:22:18 +0100:
> On Tue, May 3, 2011 at 5:05 PM, Leif Halvard Silli:
>> NOTE 1: Should the spect text say 'URL' rather than 'link'?

> Saying "link" is consistent with the language defining the very similar
> attribute @cite:

Good point. Agree.

>> NOTE 2: The suggested spec text only says this, about fragment URLs:

>> [If] description is located in a document which contains more than
>> the description itself ... longdesc MUST point to ... #fragment ...
>> [with] entire description or ... start of the description.
> 
> Not all media types that could be used for long text alternatives support
> fragment identifiers.  For example, text/plain does not. So I do not 
> think this is a safe constraint.

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?

See http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0161


That said: if a document contains nothing more than a single 
description, then the fragment URL restriction does not apply.

>> It should also always be simple to know, via the right choice of 
>> markup e.g.a heading or article or aside element etc, when the
>> description begins and ends.
> 
> Not all media types that could be used for long text alternatives use 
> markup. For example, text/plain does not. So I do not think this is a safe 
> constraint.

If a plain/text document is served, with a single description inside, 
then there will be a beginning and an end of the document.  This 
limitation, is meant as a help to the user. I have inspected some of 
the longdesc URLs in Laura's research page, and some of them are 
extremely chaotic.

But, note again, that I agree with Richard's host language limitation.

>> So, after the sentence (or after the paragraph) mentioned above, how about
>> adding this:
>> 
>>  ]]  A description SHOULD have a clear beginning and a clear end. When the
>> URL points to a page that contains more than the particular description
>> (NOTE: this includes cases where the description is located in the same
>> document as the image), the URL MUST identify the fragment where the
>> description begins (this fragment SHOULD be the container for entire
>> description).  [[
> 
> How about:

I don't see any need to full-sale replace Laura's current text. I would 
suggest we provide concrete improvement suggestions to her text 
instead. Nevertheless, some comments on things that goes directly on my 
own comments:

    [ snip ]
    When interleaved with other content, long text alternatives must be

Comment: singular form is better: "[a particular] long text alternative"

    identified as precisely as possible, for example by including a 
fragment in
    the URL identifying the start of the long text alternative. 

Comment: I don't think we win very much by not making it a MUST. Those 
who don't understand the MUST will not restrict them from pointing to 
whatever they will, while the others will with a MUST will be 
encouraged to do it correctly.

    [ snip ]

    For example, the following snippet defines an image of a chart with 
a short
    text alternative and a long text alternative elsewhere in the same
    document. The short text alternative is placed in the alt 
attribute, while
    the long text alternative is precisely linked using a longdesc URL
    including a fragment identifier:

        <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. Not sure 
we win anything by doing so.
-- 
leif h silli

Received on Wednesday, 4 May 2011 01:26:57 UTC