Re: longdesc spec text

On Wed, Apr 27, 2011 at 6:21 PM, Laura Carlson
<laura.lee.carlson@gmail.com> wrote:
> Hi Benjamin and everyone,
>
> I put your version of the spec into the spec text template [1], adding
> one additional paragraph derived from HTML 4. It is:
>
> "Since an img element may be within the content of an a element, the
> user agent's mechanism in the user interface for accessing the
> "longdesc" resource of the former must be different than the mechanism
> for accessing the href resource of the latter."
>
> This would make the logo and lightbox use cases possible. That do you
> think? Ideas to improve that paragraph?

My suggested text already says that UAs SHOULD provide access to the
long text alternative. I don't believe more normative text is necessary.
I do think that some advice about nesting would be useful, but I think
it's best reserved for the "Rendering" section.

http://dev.w3.org/html5/spec/rendering.html#links-forms-and-navigation

This point about @longdesc being inside <a> is:

  (a) Equally applicable to @longdesc being inside other controls,
such as <button>.
  (b) Equally applicable to other hyperlinking mechanisms like @cite.

Something along the lines of:

    User agents are expected to allow users to navigate browsing
    contexts to the resources indicated by the cite attributes on q,
    blockquote, ins, and del elements.

    User agents are expected to allow users to access long text
    alternative resources indicated by the longdesc attribute on img.
    For example, a user agent could allow users to navigate browsing
    contexts to the resources, or replace images with their long text
    alternatives on demand.

    Where elements exposing citation and long text alternative resources
    are also descendants of controls such as hyperlinks or buttons,
    user agents are expected to ensure users accessing the resource
    or activating the ancestor control. For example, activating the
    control might be the primary function when the control has focus,
    while resources might be accessed via a context menu.

    User agents are expected to help users discover elements linking to
    citation and long text alternatives resources. For example, a user
    agent could provide a icon button in a status bar to indicate that such
    resources are available in the document and, on activation of the
    button, show icons beside all such elements and allow them to
    receive keyboard focus.

In each case, I've tried to put the user story up front and some
suggestions of how to address it after.

> I'm also wondering if we should add the conformance checkers and
> authoring tool paragraph from my first attempt at writing the spec
> text [3]. It is:
>
> "Conformance checkers and authoring tools should inspect the URL and
> issue a warning if they suspect that the description resource is
> unlikely to contain a description of the image (i.e., if the URL is an
> empty string, or if it points to the same URL as the src attribute
> unless the document contains an id that matches a longdesc#anchor, or
> if it is indicative of something other than a URL.)"

I do think it would help to provide guidance to conformance checkers,
but I'm not sure this is the right guidance. In particular, this
guidance implies that (1) they know the URL of the document being checked,
and (2) that can request further URLs in order to check them for IDs.

We know that HTML validators often have to deal with string input rather
than a URL, and we know from Henri that at least one implementor is
reluctant to download external resources.

For example if a validator is given the string input:

    <!doctype html>
    <title>Index</title>
    <base href="http://example.com/foo.html">
    <img src="whatever.jpg" alt="whatever" longdesc="">

The longdesc URL is empty, but the validator does not know whether it
points to the document being checked or a different document.

It's kinda tempting to suggest an additional conformance class
for "HTML5 link checkers". These could be tasked with:

   1. Parsing HTML in a supplied URL according to the HTML
      specification.
   2. Verifying all the various links in that HTML (@href, @src, @cite,
      @longdesc, possibly @action and @formaction).

In the case of @src, link checkers could check that a GET responds
with an image resource. In the case of @longdesc, link checkers could
check that the @longdesc does not point to a resource of media type
image, that if it points to an HTML resource it contains the expected
fragment identifier, and that it does not point to the root or fragment
of the document that contains the element.

> Steve has some screenshots [4]. Leif has been collecting some too.
> They might be good additions to the rendering section.

I think screenshots could help a lot.

--
Benjamin Hawkes-Lewis

Received on Friday, 29 April 2011 13:33:06 UTC