W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 1999

last call: longdesc media type issue

From: Al Gilman <asgilman@iamdigex.net>
Date: Mon, 30 Aug 1999 12:26:42 -0400
Message-Id: <199908301628.MAA03358@smtp1.mail.iamworld.net>
To: w3c-wai-gl@w3.org, w3c-wai-pf@w3.org
Cc: w3c-wai-cg@w3.org
I think we can close this issue, as far as what we ask W3C format-defining
working groups to do, based on the discussion to date.  This does not in
any way force the Web Content Accessibility Guidelines to recognize any
particular novel technology as readily available in the user agent context,
not does it impede the GL group from continuing to refine the advice
available to authors in the Web Content Accessibility Techniques or a
future revision of the Guidelines.

In summary, here is the action plan that I would like to place under a
48-hour last call.  In other words, if you want to block action on this as
consensus, please speak up before 0800 GMT Wednesday, 1 Sept. 1999.

A: J. Brewer to communicate to HyperText CG:

1. No content-type constraint per_se should be imposed on the resource
referred to in LONGDESC.

2. The attribute should be used in a manner consistent with the Web Content
Accessibility Guidelines.  Please cite this document using the specific URL
<http://www.w3.org/TR/WAI-WEBCONTENT/#gl-provide-equivalents> in the
explanation of this attribute.

B: WCA WG to continue to expand as they see fit on usage guidelines, with
the general understanding that the referent of the LONGDESC is included in
the scope to which the WCAG applies whenever the IMG bearing that attribute
is in such a scope.

** Rationale:

In the last telecon there was an inconclusive discussion of the question
that came down from the HyperText Coordination Group about the possible
content type of the resource referred to by the LONGDESC attribute.

On the one hand, the description linked to by LONGDESC is part of the
safety net for users with visual disabilities.  Unless it works, and is
easy to use, there is a problem here.
On the other hand, there are non-text media forms that are adaptive in
various disability scenarios.  Using SMIL or HTTP content negotiation one
can offer both a text version and an automatic upgrade to sound for those
that can play it.  Under the range of options there could also be a
raised-line graphic or annotated SVG extract of the image.

It is appropriate for authors to be conservative in media use for LONGDESC.
 But it is not appropriate to legislate that conservatism by the means of a
content-type constraint on the referent of the LONGDESC attribute in format
specifications defining such an attribute.  The problem with using
multimedia LONGDESCs is not the formats but the implementation in User
Agents.  It is not reasonable to say text-to-speech is readily available
and sound is not.  The technical definition of content negotiation in HTTP
is sufficient for there to be a highly convenient multimedia version of a
LONGDESC.  If there is a shortfall, it is in the implementation of this
protocol by user equipment.  Thus this is a subject best addressed using
"until user agents" language in the Web Content Accessibility documents.

This is going once again through all the arguments which were considered
when the shift in language was made from "provide text alternatives.." to
"provide equivalents for audio and video."  I thought we had settled that.

To make the accessibility role of this attribute clear, it would be good
to suggest that format specifications include a link to


in their heuristic discussion of this attribute, where it is explained.

There is an open issue concerning how SMIL can incorporate audible
descriptions with sufficient flexibility.  This is under discussion between
the SMIL and PF groups at this time.  

Even leaving that issue open, I would like to close the "type of LONGDESC
referent" with the action plan set out at the top of the message.

Thank you,


>Resent-Date: Thu, 26 Aug 1999 18:12:38 -0400 (EDT)
>X-Sender: 10003479@pop.iamdigex.net
>X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0
>Date: Thu, 26 Aug 1999 18:19:44 -0400
>To: w3c-wai-pf@w3.org
>From: Al Gilman <asgilman@iamdigex.net>
>Subject: longdesc media type concern
>Resent-From: w3c-wai-pf@w3.org
>X-Mailing-List: <w3c-wai-pf@w3.org> archive/latest/1152
>X-Loop: w3c-wai-pf@w3.org
>Sender: w3c-wai-pf-request@w3.org
>Resent-Sender: w3c-wai-pf-request@w3.org
>What follows is from the raw minutes of today's joint GL/UA telecon.  I
>agreed we would hold this issue open until we get to follow up a bit more
>via email.  We did not have time to finish this on the call.
>>Date: Thu, 26 Aug 1999 17:46:17 -0400
>>From: Ian Jacobs <ij@w3.org>
>>Subject: Raw minutes from 26 August Combined GL/UA teleconference
>>3) Long description media types      
>>   See Al's proposal. [3]
>>   [3]
>>   GV: longdesc was designed to lead to something really
>>       accessible. Other than "why limit it if we
>>       don't have to", what's the benefit for making
>>       this more than text?
>>   AG: We're trying not to make it different than a standard
>>       URI reference, which doesn't limit to a specific
>>       media type.
>>   IJ: But no "type" attribute with longdesc.
>>   GV: But putting audio at the end of longdesc
>>       raises barriers.
>>   AG: But to meet WCAG, you'd need an auditory
>>       description to accompany the audio clip.
>>   JW: I don't think it's approprite to limit content
>>       types for longdesc in an HTML spec. I think 
>>       the WCAG should have jurisdiction.
>>   MK: "longdesc" also used in SMIL.
>>   GV: I'd like to register nervousness on this point.
>>       I fear people will put content out their that
>>       will impose too many layers before getting to
>>       accessible content.
>>   IJ: Drop longdesc from SMIL and use schemas.
>>  CMN: Drop IMG entirely.
>>  /* Chuck leaves the call */
>>   JW: In response to Greg's concern, I'd be willing
>>       to have non-normative language in an HTML
>>       spec that longdesc generally points to text.
>>   GV: Use the Techniques Doc to address the longdesc
>>       issue.
>>  CMN: Having text is nowhere near as good as having
>>       full markup: Put HTML at the end of a longdesc.
>>   GV: Why use a movie at the end of a longdesc?

>>  CMN: E.g., instructional videos. 
>>   GV: Why not put it on the main page?
>>  CMN: No particular way to do it. The primary version
>>       may be images plus text. The decision of
>>       what is main and what is secondary is up to the
>>       author.
>>   IJ: This sounds like a cognitive technique: put text
>>       as primary content, video as complement.
>>   JW: Longdesc should not designate plain text alone,
>>       but markup.
>>  CMN: Yes, at a minimum, refer to markup.
>>   JW: But this should not be normative in the HTML spec.
>>   GV: We need to talk about the purpose of longdesc:
>>       should limit it to a description of the image, not
>>       supplemental information about the context in which
>>       the image occurs. Similar to using alt text just
>>       for the purposes of a tool tip. Warning: if the
>>       function goes beyond a description of the image,
>>       this could lead to problems.
>>   AG: What about content negotation? You get text
>>       or video depending on preferences. Refer also
>>       to CC/PP.
>>   IJ: Distinguish
>>      a) Function of longdesc
>>      b) Content types.
>>    GV: But users may not know how to adjust clients
>>       to get different types.
>>   WG: How used in SMIL?
>>   MK: Every media object has it (audio, video, textstream, ...)
>>  CMN: Working from the HTML 4.0 spec [4]
>>       [4] http://www.w3.org/TR/REC-html/struct/objects.html#edef-IMG
>>  WC: Conclusion - we need to get consensus on the list about what's
>>     the intended use of "longdesc".
Received on Monday, 30 August 1999 12:19:27 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:16 UTC