W3C home > Mailing lists > Public > public-html@w3.org > April 2011

RE: example spec text for longdesc

From: John Foliot <jfoliot@stanford.edu>
Date: Wed, 6 Apr 2011 12:54:07 -0700 (PDT)
To: "'Matthew Turvey'" <mcturvey@gmail.com>, "'Steve Faulkner'" <faulkner.steve@gmail.com>
Cc: "'HTMLWG WG'" <public-html@w3.org>, "'James Teh'" <jamie@nvaccess.org>
Message-ID: <0a6e01cbf494$6109a3f0$231cebd0$@edu>
Matthew Turvey wrote:
> 
> The example spec text includes "...a visible indication of longdesc
> presence should be provided."
> 
> On 4 April 2011 19:50, John Foliot <jfoliot@stanford.edu> wrote:
> 
> > THE ENTIRE REASON FOR THE CREATION OF @LONGDESC IN THE FIRST PLACE
> WAS
> > THAT AUTHORS WANTED A MEANS TO ENSURE LONGER DESCRIPTIONS COULD BE
> > PROVIDED *WITHOUT* HAVING A VISUAL INCUMBERANCE ON THEIR PAGE -
> LONGDESC
> > WAS DEVELOPED TO ADDRESS DESIGNER NEEDS, BASED ON DESIGNER FEEDBACK!
> 
> The current CP also suggests being "natively free from a visual
> encumbrance" is an essential requirement, and 6 of the 9 use cases
> explicitly require the longdesc link to be invisible.

The distinction that you seem to perhaps not be grasping here is *WHERE*
the indication is presented. Content authors for the most part do not want
a visual indication *on their page* as it interrupts with their design
aesthetic, an important consideration.

However, browsers can (and we now propose SHOULD per RFC 2119 in the
example spec text) provide an indication that content like this exists:
the logical conclusion is that it should be indicated in the browser
chrome. The Opera extension TellMeMore does exactly this, and is a
workable solution to this problem. It is perhaps telling and worth noting
that many of the microformats browser extensions also do the same thing,
signaling the presence of Microdata in a page, and then allowing the end
user to consume it or not. See:
	Tails Export:
https://addons.mozilla.org/en-US/firefox/addon/tails-export/?id=2240
	Operator: https://addons.mozilla.org/en-US/firefox/addon/operator/


As Gregory Rosmaita has noted previously, @longdesc is not "hidden"
metadata, it is "discoverable" metadata - just like
microformats/Microdata. 

Since this type of information is usually contextual in nature, it also
seems quite logical to place the 'interaction' with these features in the
contextual menu: again the native support for @longdesc in Opera, the
Firefox plugin, and recent blog post on how to provide support for
@longdesc in Internet Explorer all use this pattern, so we are also
building on some precedence here: "right-click" on the image, be presented
with the link to the longer description, decide if you want to follow that
link or not. It is also worth reiterating that the developers of NVDA have
suggested (to me, in conversation) that this would be an excellent
interaction model for them to support in NVDA - they very much believe
that NVDA should be exposing native functionality to non-sighted users,
not providing 'special' interaction methods.

Discoverability of features for accessibility has always been a 'problem'
for *all* users: witness @longdesc, @summary, @accesskey and others. The
problem is not that these features do not solve problems - they do! The
problem is that the GUI browsers have to-date given up trying to
accommodate all of their users when it comes to these features. Hopefully
pointing to existing solutions such as those noted above for Microdata and
emergent extensions like TellMeMore can give the browser vendors something
to think about, play around with, expand, modify, etc. to solve the
discoverability problem.

Fix the browsers, don't mess with legacy HTML: evolution, not revolution
is, I believe, one of the mantras...
http://www.w3.org/TR/html-design-principles/#evolution-not-revolution 

	"Most often, however, it is better to evolve an existing design
rather than throwing it away."

JF
Received on Wednesday, 6 April 2011 19:54:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:27 GMT