Re: example spec text for longdesc

Hi laura,

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

the display and format of most html features are stylable using CSS
what is the issue with having an indication of the presence of longdesc as a
default, which can then be styled away if required by developers or users?

regards
Stevef

On 6 April 2011 21:05, Laura Carlson <laura.lee.carlson@gmail.com> wrote:

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



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