Re: longdesc spec text

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

Okay. Thanks Ben.  I pulled that paragraph out of the spec text.
http://www.d.umn.edu/~lcarlson/research/ld-spec-text2.html
It can go into the rendering section unless people think that isn't a good idea.

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

Oh... this is good Ben. Thank you very much. I reworked it a little
and put together a draft for the rendering section. I pulled out the
cite additions as cite isn't within the scope of our longdesc change
proposal. If Ian wants to add this type of info for cite he can or
people can file cite bugs later.

Anyway check out:
http://www.d.umn.edu/~lcarlson/research/ld-rendering.html

Ben and everyone, please let me know what should be improved.

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

That is a good format.

> I think screenshots could help a lot.

I have added some in the rendering section draft.

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

Did you get that impression from Henri? He said that it would be
trivial to add some checks.

Someone proposed this text to me:
"Conformance checkers and authoring tools should inspect the
description resource URI and issue a warning if the URI cannot
reference a text description of the image (i.e., if the URI is empty
or otherwise invalid, if the URI reference has a mime type other than
text/*)"

Leif has proposed requiring longdesc URLS to have #fragment so that
they could be more machine checkable. It would make it more complex
for humans but tools could catch more errors. What do you think?

I'm not sure. It would be good to get something in the spec that
helps, but I don't know what that is yet.

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

A conformance class for HTML5 link checkers is a possibility. What
"HTML5 link checkers" currently exist? Do authors use link checkers
more than validate? Maybe we could have some type of longdesc rules
for both classes of tools so more authors get longdesc right?
Thoughts?

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Monday, 2 May 2011 11:41:42 UTC