Re: Longdesc change proposal update

On Mon, May 9, 2011 at 4:16 PM, John Foliot <jfoliot@stanford.edu> wrote:
> 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.

Yes, I agree. But then it is not a generic solution to providing
longdesc to sighted users. I am mostly concerned that something has to
be there no matter what, which will be the encouragement that
publishers need to make use of it. A entry in the context menu is IMO
still the best way to achieve that. We could add on the rendering page
that UAs are encouraged to additionally expose visual indicators when
people have turn image rendering off, e.g. a button to navigate to the
longdesc URL, display the alt text as a link with the link going to
the longdesc URL, or a snippet from the longdesc URL text if there is
space available underneath the alt text with a link behind the snippet
to the full content. Also, the full content could be rendered in an
overlay. It might make sense to have this as examples of additional
rendering means. I'm just concerned about the main rendering being
there and being consistent across browsers.


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

Agreed. And by explicitly mentioning the context menu link - which
should be trivial to implement for browsers - we make a very good
argument for it to be discoverable to all sighted users.


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

agreed

> which to me means that this ultimately must be a user-choice preference in
> the browser.

No, not necessarily. We can have all browsers (at least all desktop
browsers) support a context menu link. And recommend further additions
through user preferences.

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

agreed

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

You know, you could expose the list of available images through an RSS
feed. But then that doesn't provide you with much visibility.

Are you saying that you'd like an icon to pop up if there is at least
one image on the page that has a longdesc defined? Other than for
validation, what would be the use case?


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

ok.


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

The problem is not so much the user, but the Web developer and the
publisher. They build their pages with certain expectations. If they
rely on a context menu in one browser, but a different browser does
something different that screws with their layout, then that's awful
to develop a consistent user experience for.


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

I think neither of us was arguing for another solution. ;-) I'm
utterly confused about this part of the argument now. :-)


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

I just meant the part of whether a URL is already loaded or not - that
is not something you can specify, but that is something that the
browser has to figure out at runtime. For other parts of the longdesc
specification: I agree, we have lots of concrete specification to do
and I hope I was able to contribute.

Cheers,
Sllvia.

Received on Monday, 9 May 2011 07:17:53 UTC