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

Re: example spec text for longdesc

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sat, 26 Mar 2011 04:59:43 +0100
To: Laura Carlson <laura.lee.carlson@gmail.com>
Cc: Aryeh Gregor <Simetrical+w3c@gmail.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>
Message-ID: <20110326045943216400.603e7de5@xn--mlform-iua.no>

Laura Carlson, Fri, 25 Mar 2011 12:36:32 -0500:

> Based on Lachlan's and Henri's feedback I deleted the sentence,
> "Conformance checkers should issue errors if the longdesc URL has
> certain file suffixes, such as .gif, .jpeg, .png etc.)", 

+1 This wasn't as simple as I must admit that I thought it to be.

> I could put something like it back if people think it would be
> useful to have it as a warning. Do you think that the example
> spec text is better with or without it?

Instead of suffixes, we could require the @longesc URL to point to a 
#fragment ID. Such a thing should be easy for conformance checkers to 
check for, and simple for authors to understand. And, instead of 
suffixes, we should define the exact format(s) of @longdesc resources.

1) Specify the longdesc resource format: 
    HTML5 specifies quite exactly the format of img's src: "a valid 
non-empty URL potentially surrounded by spaces referencing a 
non-interactive, optionally animated, image resource that is neither 
paged nor scripted". And in a NOTE below that paragraph, it describes 
which image formats this includes (amongst them one page PDFs) and 
precludes. Note especially that @src cannot contain interactive images. 
That is: no links and - I think - also no linkable fragment identifiers 
inside the image.
    The format of @longdesc should be described in a similar way. 
Proposal: @longdesc MUST point to a XHTML or HTML file. What? Banning 
audio and video? Yes. Authors can add audio/video in the longdesc HTML 
file. Even if it works, we do not need to say that it is *valid* to let 
@longdesc point directly to a audio or video file - because such a 
thing would be of extremely minuscule benefit.

2) Spec that longdesc URLs point to a fragment identifier
   This might be a radical proposal. But perhaps be not.
   Pros and Cons:
        * In *effect*, such a requirement would, to a high degree, be a 
guarantee that HTML5-valid non-rotten longdesc URLs leads to an 
        * A lot of current uses of @longdesc in the wild would be 
invalid per HTML, including some valid uses. (However, I note on your 
longdesc research page, that several of them do make use of fragement 
ids. Especially those that have created a longdesc description page 
which contains more than one longdesc. And I must ask: if the @londesc 
points to a page, the won't e.g. a screenreader read the title of the 
page and other possibly irrelevant stuf? Won't that be avoided if it 
points to a fragment ID? Perhaps someone should test?) 
        * It is probably good authoring practise to keep long 
descriptions together in dedicated 'long description page', rather than 
creating several pages - one for each image. Such an authoring practise 
nearly gives itself as the logical thing as long as we require the 
@longdesc to point to a fragment.
        * Requiring a fragment ID is also inline with the CP's 
emphasize that @longdesc need not be a on a different page, but could 
point to a fragment ID on the current page.

Summary - text proposal:

 Replace this:
    The URL references a separate document, a content fragment in
    a separate document, or content fragment within the same 
    document as the image.

 With this:
    The URL references a fragment identifier located in a separate
    document or in the same document as the image.

(I did not say "HTML document" - it probably should be emphasized some 
place though. In the text above, you could though place a link on the 
word 'document' to http://dev.w3.org/html5/spec/dom.html#html-documents 
. )


leif halvard silli
Received on Saturday, 26 March 2011 04:00:18 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:11 UTC