Re: Moving longdesc forward

On 5/4/11 9:22 AM, "Leif Halvard Silli" <> wrote:

Leif Halvard Silli, Wed, 4 May 2011 14:45:08 +0200:
> Geoff Freed, Wed, 4 May 2011 08:28:23 -0400:
>>> May be, w.r.t. 'structured host language', we could learn from the @src
>>> definition and say that longdesc resources should be located inside
>>> 'HTML and XML files with <html> as root element'.
>> ===
>> GF:
>> I'd be hesitant to put this restriction place because in some cases
>> it imposes an extra step on the user.  For example, if I want to use
>> a plain-text document, or an accessible PDF, to deliver my longdesc,
>> are you saying that I must first lead users to a structured document
>> from which they select a link that *then* leads to the
>> plain-text/PDF longdesc?
> Would you agree with me if we made it a SHOULD?
> To answer your question: Yes you would. OR you could paste the content
> into HTML file and serve it as longdesc document. Or the longdesc
> document could include a link to the PDF file, with an explanation
> saying "See this link to PDF document with description, but note that
> only first 3 pages are relevant."
> Can we make it a MUST still?

HTML5 says that unless content is served as UTF-8, then links etc can
not expected to always work.

So, one way around the porridge (Norwegian expression) could be place a
warning in the spec saying that users are likely to experience problems
unless the longdesc resource is a html document or a xml document with
html as root element.


I'm not crazy about MUST, and I'm also not crazy about making users select two links in order to receive certain types of long descriptions as it introduces a (or another) chance for users to get lost.  However, I also would prefer that long descriptions be structured (for all the obvious reasons) so I can be happy with SHOULD.


Leif H Silli

Received on Wednesday, 4 May 2011 13:48:12 UTC