RE: Longdesc change proposal update

Silvia Pfeiffer wrote:
> 
> 
> That plugin adds an icon to every image on a page. @alt text doesn't
> do that: it @alt text is there for occasions where images are not
> rendered or for AT, but not for common rendering. If the icon appeared
> when I had images turned off, that would be ok.

Hi Silvia,

Dirk's plugin is based on an idea I had, that he and I discussed, and he
knocked together as a proof of concept for me (for which I am very
grateful). It is not intended (nor was it ever) to be a definitive
implementation scheme, but rather an illustration of how browsers *might*
consider processing images with @longdesc. 

One thing that browsers could do however is provide this kind of
indication via a toggling mechanism: users could turn this type of visual
indicator on or off via user preference settings, with a default setting
of off.

The point of the illustration was that we've heard that lack of
discoverability for sighted users who may need/want longer textual
descriptions was a flaw of the attribute. The plugin shows that this need
not be the case, there are many ways that a visualization could be
provided if the end user wanted such a mechanism. Dirk's plugin places an
icon in the lower-right corner, Chaals' Opera extension places an icon in
the browser chrome. The real point is that the presence of @longdesc
content need not be completely hidden by the browsers, although at the
same time most users will not need or want a visual indication.

> 
> None of the rendering prevents any kind of implementation. In fact,
> the spec will never prescribe to UAs how to render things - it only
> ever provides recommendations. I am just saying that one
> recommendation only is sufficient and that recommendation should be
> context menu IMHO.
>
<snip>
> 
> It's not productive to have 4 browsers implement 4 different means of
> exposing the longdesc attribute. That will just lead to more
> fragmentation and again less people making use of the attribute. And
> it leads to poor usability because people cannot expect one means
> where to find the information. All of this works against us.

There are 2 problems here that need to be solved in tandem. 

The first is how do we indicated to sighted users that there is a longer
textual description associated with a complex image (without changing the
page's visual design - the designer has specifically not provided for a
visible link or redundant text on screen, and you yourself noted that if
we started to force an indication you would go back and remove any
longdesc content you had previously added). This one is tough, because in
effect we both want and don't want a visual encumbrance simultaneously,
which to me means that this ultimately must be a user-choice preference in
the browser. While the use of plugins and extensions today effectively
provide a toggling of sorts (you want that functionality, install the
plugin), I would hope that browsers would instead implement some form of
indicator function natively. Here however the type of visual indicator
need not be identical from browser to browser, although I am personally
sensing that a browser chrome indicator is appealing to many; for example
many browsers today indicate, via the address location bar, when pages
also provide an RSS feed, although this would still be a problem for users
of screen magnifiers. 

The second problem is how to actually access the longer description, and
here I agree that the 'activation' mechanism would likely best reside in
the context menu. In discussing the @longdesc issue with the developers of
NVDA at CSUN, both James and Michael also indicated that they thought this
made the most sense.

How we write this up in the spec however is a task for technical authors,
and I ain't one of those <smile>.

> 
> If one browser implements the context menu link to the long
> description and another implements the drop-down menu in the browser
> toolbar, then I as a user cannot get used to one way of finding the
> longdesc link, but have to learn two different way depending on which
> browser I am using.

This argument is fairly weak, as most users don't flip around from browser
to browser; this behaviour is usually reserved for geeks like us. It would
be good that the browsers did things in a similar fashion, but I can also
recall numerous times struggling with a Mac because it doesn't operate
like a PC, yet neither platform appears willing to undo their specific
implementations in favor of what the other guy does. People get used to
their daily tools operating the way they do, regardless of the minor
differences one tool has over the other - they pick one that works for
them, and use that tool.

> 
> Are we arguing past each other? Maybe we are agreeing that the
> longdesc attribute on the image should be made available as a URL,
> which AT can use to read out the long image description on demand?

Perhaps. One key distinction that none of the other proposed solutions
allows today however is referencing a full URL that could point to a
separate page: those who wish to obsolete @longdesc are arguing against
this functionality. (or that the URL be plainly visible at all times)

> Whether the long description is already loaded into the browser
> because it's on the same page, or has to be retrieved by following the
> link is up to the situation in which the browser finds it and really
> doesn't need to be specified.

No, as this is one reason why we have a problem today with @longdesc - it
was under-specified in HTML 4.0. We need to do better today.

JF

Received on Monday, 9 May 2011 06:16:41 UTC