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

Hi all,

my understanding and thoughts:

1.the html task force seek to have an agreed  position on longdesc in a
short time frame
2. continuing to refine/change/update the extremely detailed change proposal
Laura has developed means that it is difficult to achieve agreement as
nobody is sure what they are agreeing to
3. What the HTML wg chairs require when they reconsider this issue is [1]:

   - use cases that specifically require longdesc,
   - evidence that correct usage is growing rapidly and that that growth is
   expected to continue, or
   - widespread interoperable implementation.

4. due to the  requirements above any change proposal should concentrate on
providing such evidence. the proposal should be succinct as is possible so
as not to drown out the new evidence.

5. we should not seek at this time to expand the scope of what is required
which is i believe:

A feature that provides an explicit and unambiguous method of associating an
image with a description of the image.

6. From discussions at the San Diego face 2 face we should attempt to
achieve consensus on it NOT being a requirement that  longdesc only be
available to users of AT. In discussions with the developers of NVDA, what
they do not want is to implement an AT only method of access, they want the
browsers to provide the functionality.
7. in regards to the above i would suggest that recommending browsers to
implement longdesc in a way that can be available to any user will solve
many of the problems that are perceived as being part of longdesc, while not
taking away the essential capability of longdesc to be an "unambiguous
method of associating an image with a description of the image"


If we can agree on the points above I think a change proposal that
encapsulates the above could be produced in short order.


regards
stevef


[1]
http://lists.w3.org/Archives/Public/public-html/2010Aug/att-0112/issue-30-decision.html

On 4 April 2011 19:28, Laura Carlson <laura.lee.carlson@gmail.com> wrote:

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


-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html