Re: example spec text for longdesc

Hi Matt,

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

A very important requirement is to respect a web page's visual design
and have no *forced* visual encumbrance. It should be some type of
user choice.

Access to the content of the longdesc attribute for the sighted could
be similar to television closed captions. Closed captions are encoded
or invisible to the sighted by default and must be decoded or made
visible. There is a reason that closed captions (as opposed to open
captions) are the default on televisions. Sighted people rarely
require them. To them, they are visual noise. Clutter. Redundant. But
if a sighted person wants to enable closed captions (longdesc is not
hidden meta-data) they can do so via a user preference built into the
system menu. It is a user choice. Televisions do not have a default
on-screen visual indicator. There is no forced visual encumbrance.
This is by design.

The best implementation of for longdesc that I have seen to date it
Chaals' Opera TellMeMore extension. 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."
https://addons.opera.com/addons/extensions/details/tellmemore/1.2/

The example spec text that Steve wrote and the example spec text that
I wrote differ somewhat in this regard. What I drafted says,

"User agents should allow users to follow such description links. To
obtain the corresponding description link, the value of the attribute
must be resolved relative to the element. User agents should provide
the user an option or preference to access the content via a device
independent mechanism. For specific details consult the User Agent
Accessibility Guidelines (UAAG 2.0) and its implementation documents.
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
"longdesc" resource of the former must be different than the mechanism
for accessing the href resource of the latter."
http://www.d.umn.edu/~lcarlson/research/ld-spec-text.html

I think this could be worked out with some combination of the two spec
text examples. Maybe it needs so say something about discoverability.
There are other use cases* that could benefit from longdesc.
http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Other_Use_Cases

Matt, do you have suggestions of how to word this better so that user
agents provide an option to reveal longdesc but it doesn't intrude on
web page visual design?

Having an option in the chrome like tellmemore would seem to work
well. But I don't know how difficult it would be for other browser
vendors to provide this functionality. So how difficult would it be in
the major browsers to do this?  Input from our browser vendors here
would be most appreciated.

Thanks.

Best Regards,
Laura

* There are other elements that could possibility benefit from long
descriptions too as Jonas pointed out earlier.

On 4/6/11, Matthew Turvey <mcturvey@gmail.com> wrote:
> On 4 April 2011 18:36, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
>> it is not intended that longdesc will 'hide accessibility' in fact it is
>> the
>> opposite as I have attempted to articulate in the example spec text [1].
>> Of course browser vendors cannot be forced to expose longdesc in a device
>> independent way, just as they cannot be forced to expose title attribute
>> content in a device independent way, but authors can work around browser
>> support issues.
>
>> [1] http://www.html5accessibility.com/tests/img-longdesc.html
>
> 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.
>
> If being hidden is not an essential feature, updating the CP
> accordingly would be helpful.
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Rationale
>
> ~Matt
>
>


-- 
Laura L. Carlson



On 4/6/11, Matthew Turvey <mcturvey@gmail.com> wrote:
> On 4 April 2011 18:36, Steve Faulkner <faulkner.steve@gmail.com> wrote:
>
>> it is not intended that longdesc will 'hide accessibility' in fact it is
>> the
>> opposite as I have attempted to articulate in the example spec text [1].
>> Of course browser vendors cannot be forced to expose longdesc in a device
>> independent way, just as they cannot be forced to expose title attribute
>> content in a device independent way, but authors can work around browser
>> support issues.
>
>> [1] http://www.html5accessibility.com/tests/img-longdesc.html
>
> 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.
>
> If being hidden is not an essential feature, updating the CP
> accordingly would be helpful.
>
> http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc#Rationale
>
> ~Matt
>
>


-- 
Laura L. Carlson

Received on Wednesday, 6 April 2011 20:06:21 UTC