longdesc (was Re: minutes: HTML Accessibility Task Force Weekly Call 2011-03-31 [draft])

Hello Steve, Gregory, Chaals, Janina, Judy, and everyone,

On 3/31/11, Gregory J. Rosmaita <oedipus@hicom.net> wrote:

[snip]

> http://www.w3.org/2011/03/31-html-a11y-minutes.html

[snip]

> longdesc

[snip]

>
>    JS: We're looking to SF to help draft a proposal based on
>    conversations at the F2F. LC has done great work, but calling it a
>    change proposal is difficult because it seems to transmute several
>    times a day at the moment and

Per the HTML decision policy "Authors of Change Proposals are strongly
encouraged to seek consensus and revise their Change Proposals to gain
more support."
http://dev.w3.org/html5/decision-policy/decision-policy.html

We are building a document. Not setting it in stone yet. Steve's and
everyone's ideas are very much welcome. We are gathering evidence.
Adding links. Building a case. Seeking consensus.

It is called constructivism. A wiki document helps to do that. In
building consensus, I have been using a constructivist approach and
listening to everyone.

>    we need to extract a solid core from it.

Leif created a "shadow" copy the InstateLongdesc proposal in February.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc-Shadow

Leif's "shadow" has ideas about Conformance checkers examining
longdesc URLs and issuing warnings if they suspects that the
description resource is unlikely to contain a description of the
image. I incorporated some of Leif's ideas  into the sample spec text.

What does everyone here think of this paragraph from the example spec text:

"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.)"
http://www.d.umn.edu/~lcarlson/research/ld-spec-text.html#long

It has been discussed somewhat on public-html.

If the "imagedescription" copy of "InstateLongdesc" that Steve
produces good ideas, we can certainly add them to the InstateLongdesc
proposal too.

>    <oedipus> change proposal strategy note: once the change proposal
>    has reached maturity, any additional information pertinent to the
>    issue should be logged using the wiki page's "discussion" page
>    feature, so as to maintain the stability of the actual CP

An easy way to do this is that once a change proposal is indeed
complete, it can be simply referenced by a revision-dated permalink.

But we are not there yet.

Comments can be made on lists or on discussion pages or via a
dedicated comments page.

I have made a dedicated ISSUE 30 Change Proposal Discussion and
Comment Forum for Issue 30 CPs at
http://www.w3.org/html/wg/wiki/ChangeProposals/Issue30CPForum

All input is greatly appreciated.

>    <oedipus> LauraC's original CP:
>    http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc
>
>    JF: The most important take away from the F2F was a relaxing of the
>    stand on whether the presence of a longer description mechanism
>    should be visible to sighted people. In listening to a lot of
>    feedback and discussing it, there was agreement that having a visual
>    indicator was useful though.

I agree that a visible indicator may be useful in some other use cases.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Other_Use_Cases

The best implementation of for longdesc that I have seen to date it
Chaals' Opera TellMeMore extension.
https://addons.opera.com/addons/extensions/details/tellmemore/1.2/

TellMeMore respects a web page's visual design yet provides critical
functionality. Some of the implementations don't. TellMeMore will
"Find things that have more description available, and show them on
demand. Where images (or something else) have a longdesc attribute,
the extension notifies by changing its icon and title, and enables the
user to see a list of the descriptions available, in its popup. When
the user selects an item in the popup, a new window opens with the
description in it."

>    <oedipus> CP from SD F2F:
>    http://www.w3.org/html/wg/wiki/ChangeProposals/imagedescription

Steve, is there a reason that the direct copying and forking of the
original proposal has been re-scoped exclusively to images?

Last week Jonas talked about how descriptions could be useful on other
elements. That makes since to me. TellMeMore seems to be headed in
that direction too.

It is possible that the longdesc attribute could be used on other
elements if it is reinstated into HTML. It might useful for providing
descriptions for SVG, tables, figures, forms, and video. For example
it could be used to provide semantic, programmatic determinable video
transcripts and descriptions. Silvia started a draft on transcripts
after I commented on her blog.
http://blog.gingertech.net/2011/03/29/webvtt-explained/
http://www.w3.org/WAI/PF/HTML/wiki/index.php?title=Media_Alt_Technologies&oldid=3570#3:_Use_.40longdesc_for_providing_a_link_to_a_file_with_the_full_transcription

Quite a few use cases may well be served by longdesc. But when the
forked change proposal is titled "imagedescription" with the heading
"Provide a dedicated description mechanism for images in HTML5" those
use cases are automatically ruled out. Why?

>    JF: The general feeling was that it would be a "should" requirement,
>    rather than a "must" requirement. The belief is that the single
>    widest barrier to the adoption of longdesc to date is that browsers
>    haven't been able to convey the presence of a longdesc to users and
>    this is why it's been broken.

A "should" is fine with me.  I suspect that browser vendors would
object to a "must".

>    <oedipus> note: PFWG has formally submitted its
>    recommendation/resolution on Verbose Descriptor Requirements
>    http://www.w3.org/WAI/PF/HTML/wiki/Verbose_desc_reqs#Requirements
>
>    JS: In a parallel effort, PF in response to this discussion and
>    specifically in response to many f the issues raised during the
>    first round of consideration, have tried to come up with a set of
>    requirements.
>
>    <oedipus> 1. A programmatic mechanism to reference a specific set of
>    structured content, either internal or external to the document
>    containing the described image.
>
>    <oedipus> 2. A way to inform users and authors that a description is
>    present/available.
>
>    <oedipus> 3. A device independent way to access the descriptive
>    content.
>
>    <oedipus> 4. An explicit provision that accessing descriptive
>    content, whether internal or external to the document containing the
>    image, does NOT take the user away from the user's position in the
>    document containing the image where the verbose descriptor was
>    invoked;
>
>    <oedipus> 5. A way to provide user control over exposition of the
>    descriptor so that rendering of the image and its description is not
>    an either/or proposition. (A visual indicator of the description
>    should NOT be a forced visual encumbrance on sighted users by
>    default).
>
>    <oedipus> 6. A method to reference a longer description of an image,
>    without including the content in the main flow of a page.
>
>    <oedipus> 7. 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 verbose descriptor resource of the former must be
>    different than the mechanism for accessing the href resource of the
>    latter.

Last week Jonas suggested an eighth requirement which I added to the
"Verbose desc reqs" document. It is "Ease of use". I think it is a
good addition. longdesc is a simple link. It is easy.

>    GJR: These requirements are attribute and element agnostic. These
>    are specifically to define what functionality is needed for a
>    verbose description mechanism. They're not requirements for longdesc
>    specifically.

longdesc meets all of these requirements. Nothing else to date does.

>    JS: The aim is for the TF to look at these and either modify or
>    endorse them.

I think that the requirements are good.

I hope that going forward the Accessibility Task Force can follow
consensus pursuant to the Task Force consensus procedures and work
statement at:
http://www.w3.org/WAI/PF/HTML/consensus-procedures
http://www.w3.org/WAI/PF/html-task-force#approach

Some task force members are not afforded any (as in zero) time off
from their jobs and other obligations to work synchronously. We send
regrets. Some TF members do not have the privilege and luxury of
attending teleconferences. Face-to-Face meetings in particular pose
undue burden. Input and consensus should be sought asynchronously for
this people pursuant to the Task Force consensus procedures.

>    JB: Can the TF confirm a welcome to Laura to coordinate directly
>    with the TF on this?.

Thank you very much. I have and will continue to do so. I am most
eager for Task Force help and input.

Please chime in.

Best Regards,
Laura

-- 
Laura L. Carlson

Received on Monday, 4 April 2011 18:29:26 UTC