RE: Moving longdesc forward: Recap, updates, consensus

Laura Carlson
>
> Steve, some time ago I think you mentioned that the proposal was too
> long. We could eliminate the reference section and link to that
> material on the longdesc research page. That might help. What do you
> think? Do you or  anyone have concrete suggestions to make the
> proposal better?

Hi Laura,

The overall length of that document is I think a concern (if printed on 8.5 
X 11 paper it runs 15 pages long), which is why Steve and I had discussed 
working on a more succinct version earlier this spring.  I would suspect 
that a very terse, striped down Change Proposal (a "one-pager" or "Executive 
Summary") would be easier to digest, with referring links pointing to the 
wealth of evidence that support the basic assertions:

{first pass follows}

Summary:
  Include the longdesc attribute from HTML 4 in HTML5 as an allowed 
attribute on images.

Rationale:
  Multiple and detailed Uses Cases[1] have been identified that directly and 
specifically require longdesc. The Primary Use Case is that Longdesc affords 
authors the native capability to provide information that is essential for 
blind and visually impaired users but would be redundant for sighted users 
and unacceptable to visual designers' aesthetics.[2] Other use cases have 
also been identified and annotated in the supporting research attached to 
this Change Proposal.[3]

Use Cases:
 - An image's content is visually apparent and typically redundant to a 
sighted person, and/or
 - It is unacceptable to a marketing department or web author to use another 
technique due to aesthetic considerations. Many artists, designers, and 
marketers do not want their visual designs changed/ruined with visible link 
text. (Longdesc is natively free from a visual encumbrance.), and/or
 - The image also serves as a link. With longdesc it is programmatically 
possible to separate the activation of the longdesc for exposure from the 
UA's universal link activation action (which is usually activated with the 
ENTER key, the SpaceBar, or by mouse click), so that the linked image 
retains the expected behavior in response to user interaction while a 
discrete mechanism is used to retrieve the long description. , and/or
- The description is external to the document.

  Other use cases have also been identified that would potentially impact on 
other (sighted) users [4]

Responses to arguments against retaining longdesc:
 * Hidden Meta-data Fallacy [5]
 * Something for Everyone, Not Everything For Anyone [6]
 * Recent Research on Online Tutorials and Documentation [7]
 * Recent Research on Guidelines, Laws, Policy, and Standards [8]
 * Implementation to date [9]
 * Recent Research on Users [10]
 * Suggested Alternatives Are Not Viable Solutions [11]
 * Related Solutions Do Not Negate the Need for longdesc [12]

Conclusion:
  longdesc Should be Included in HTML5 [13]

Details:
 * Main Spec Changes:
     (This should be complete and as detailed as possible, taken from 
http://www.d.umn.edu/~lcarlson/research/ld-spec-text2.html)

 * Changes for other sections:
     (This should be complete and as detailed as possible, again as above)

Impact
 - Makes longdesc more useful, robust, and encourages better user agent 
implementation.
 - Requires conformance checking to accept the attribute as valid, and would 
imply maintaining the existing requirement on Authoring Tools to allow the 
author to use this functionality. It would maintain conformance of HTML-4 
tools and content, rather than the current expected change leaving them 
non-conforming.

References [14]

(where all [#] entries link to the current W3C wiki document, which 
could/should be renamed as "Evidence and Justification to Support the 
Reinstating of longdesc" - or some such)


<opinion>
I would omit any text in this Change Proposal that discusses "Expanding 
longdesc Use" *at this time*, as this is *new* functionality not currently 
in existing specifications, and muddies the water somewhat.

While I agree that thinking about and discussing these things further 
strengthens the case for a mechanism such as longdesc, and shows how 
longdesc could be improved for greater usefulness, I personally think that 
these additions should be pursued as Bugs/Feature Requests outside of the 
larger "Reinstate" thrust of this Change Proposal. Looking to get these 
additions into the spec at this time opens the door for continued "debate" 
which slows overall progress - it introduces churn and grind. Continued 
discussion on how to improve longdesc is good: allowing that discussion to 
bog us down from getting longdesc reinstated *NOW* is not so good.

Get longdesc back to where it is/was in HTML 4.01/XHTML 1.1, and *THEN* we 
can look to improve it via the Bugs method.
</opinion>

Laura I think it is imperative that we have this ready in the next week or 
so, and while I feel like I have more on my plate than I can currently 
process sanely, I would be happy to help get a "Readers Digest" version of 
the Change Proposal, based upon what I suggested above, ready to present to 
the [text] sub-team next week if you so wish.

Thoughts?

JF

Received on Thursday, 5 May 2011 20:47:24 UTC