Re: Moving longdesc forward

On Wed, May 4, 2011 at 9:46 PM, Leif Halvard Silli
<xn--mlform-iua@xn--mlform-iua.no> wrote:
>>>  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.)

However much we like HTML better than PDF, I don't think we can take
the position that HTML is a web format and PDF is not.

>>> 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?

There's no more reason to say that then to require that any external
document referenced by @longdesc "exactly describes a specific
image, and nothing more". (Note PDF, like HTML, supports navigation
to fragment identifiers.)


>>> 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.

UAs may launch external programs in order to access a resource.
Authors cannot know which media types are opened with an external
program or not.

> 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.

I'm not sure about the use case (reusing @longdesc for timed media text
alternatives) but I do not think that requirement would make things better.

> 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."

Not happy with this.

- I think opposing SHOULD and MAY like that is odd.
- Which vocabulary is used for the root element does not tell you the vocabulary
used for structuring the long text alternative, so it's irrelevant.
- Using HTML does not guarantee the text alternative is appropriately structured
or even text.
- We should not suggest that @longdesc may be limited in utility to
one user group,
rather than anyone who can consume text alternatives.

Preferring HTML over PDF seems like good linking policy for HTML documents
generally.

What if we proposed a note to the end of
http://dev.w3.org/html5/spec/links.html#links:

"Note: User agents may not be able to open resources of a different
format to the
current document, or may have to resort to a plugin, so linking to
resources in the
same format are to be preferred. Links to resources in other formats are best
described as such."

--
Benjamin Hawkes-Lewis

Received on Thursday, 5 May 2011 07:49:40 UTC