Re: Moving longdesc forward

Geoff Freed, Wed, 4 May 2011 13:18:36 -0400:
> On 5/4/11 12:47 PM, "Leif Halvard Silli":
>> Leif Halvard Silli, Wed, 4 May 2011 18:25:59 +0200:

>> "A technology that tires to fit everywhere ends up fitting nowhere."
>> 
>> Therefore we should restrain ourself from making it seem as if it fits
>> equally well everywhere, for all things and for all formats.
>> 
>> GF:
>> I agree.  Although 

I am in 100% agreement, but ... Smile. I have the feeling I am talking 
to myself. But I'll give this issue final go. See below.

>> it’s probably the case that the vast majority of 
>> longdesc material *can* be made to fit into an HTML page, I don’t 
>> want to create an unnecessary limitation on current or future 
>> technology.

Stating what's valid/recommended isn't, itself, technology limitation.

>>  I don’t want to make it impossible 

Like I said above: we create no impossibility. Links are links. But a 
web browser is no PDF viewer. Yet. (Webkit perhaps is.)

>> for authors to launch a longdesc via an accessible PDF

* An 'accessible PDF' in the context of @longdesc means "a brief, 
accessible PDF which exactly describes a specific image, and nothing 
more", right? Not a link to a book in PDF format. Most authors that are 
able to produce brief PDFs with image descriptions would also be able 
to create the same description in HTML. If some users prefer PDF over 
HTML, then - by serving both on the same URL - those that prefer PDF 
over HTML, can be served that format. Links to PDF brochures should be 
provided via normal links.

Half serious: what about large scale images for the hard of seeing? 
(Serous answer: Yes, if there were a MIME format for large images.)

>> or a tactile-graphics source file,

* Do you then count in the future possibility that even sighted one day 
may read such images? Tactile-graphics, if I understand, are not image 
descriptions in a strict sense but a translation into another image 
format. Of course, via content-negotiation, and provided that one 
*also* serves a HTML description, it could be possible to offer that 
format *only* to those users that has a UA which prefer that format 
over HTML.

It sounds like true check-list accessibility  ("Yes, I have provide a 
longdesc.") to provide a link to tactile-graphics, an nothing more, 
when not even most blind users have equipment to read it.

>> or to launch a free-standing media player (which may be more
>> accessible than an embedded player).

* This sounds like a possible use case for @longdesc on <iframe>, 
<object>, <audio> and <video>, which are the elements that embed 
players. However, it depends on what you mean: the longdesc link is a 
link for accessing a resource, it is not for launching players of this 
sort or another. Thus, I am not entirely certain that this use case 
really fits. If you want to launch video file in another player, then 
then that is similar to open a image file in an external viewer: you 
should not need longdesc do do that. And, if you do need longdesc for 
that, then I believe you should indeed have to first open the 
description file and *then* click the link.

In as summary think we have two options:

 ONE: say that users that *do* want a non-HTML format eventually must 
be provided access to them as links in the description document. Or 
directly in the main document.

Or,

 TWO: Content negotiation. Let those that prefer some non-HTML format 
over HTML get what they want via content-negotiation, without 
distracting those that prefer HTML, but nevertheless recommend to 
always serve HTML.

Here is another attempt at a definition:

 "The longdesc link SHOULD always point to an HTML resource (a HTML 
document or to an XML resource with <html> as root element), but MAY 
via MIME content-negotiation point to additional resource that meets 
the requirement that it offers a focused description of the content of 
the image in a format that provides enhanced accessibility to the 
content of the image for some usergroup." 

But I am really in doubt about the latter part.
-- 
Leif Halvard Silli

Received on Wednesday, 4 May 2011 20:47:11 UTC