Implementing longdesc ... Re: 48-Hour Consensus Call: InstateLongdesc CP Update

I specified the implementation of longdesc in Opera, and I implemented
longdesc as an extension in TellMeMore. I have used other implementations,
so here are some thoughts.

TL;DR: Implementing longdesc isn't complicated. It has been done more or
less independently numerous times, and each time while there have been
differences, the implementation works, and if it isn't the most elegant
solution it doesn't cause active harm anywhere.

This probably overlaps with things others have said (specifically John and
Silvia). I let that happen rather than re-reading the thread, because
otherwise I would not be able to post this until next week.

On Tue, 18 Sep 2012 00:49:43 +0200, Silvia Pfeiffer
<silviapfeiffer1@gmail.com> wrote:

> On Tue, Sep 18, 2012 at 8:26 AM, John Foliot <john@foliot.ca> wrote:
>> Joshue O Connor wrote:
>>>
>>> I think we need to step back further John. We need to work out what it
>>> should be before we ask any vendor to implement a solution.

Agreed.

>>> They will certainly support some form of long descriptor if it is
>>> present in the spec.

Like John, I simply don't believe this to be self-evidently true, and
suspect it is nothing more than wishful thinking. (I hope I am wrong)

> The thing is: if you read the HTML4 spec, there really is nothing
> stated about how the UA is supposed to expose it.
> http://www.w3.org/TR/html401/struct/objects.html#h-13.2
>
> Quote:
> longdesc = uri [CT]
>     This attribute specifies a link to a long description of the
> image. This description should supplement the short description
> provided using the alt attribute. When the image has an associated
> image map, this attribute should provide information about the image
> map's contents. This is particularly important for server-side image
> maps. 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.
>
> This paragraph creates a problem without solving it. It states that
> the UA should expose a longdesc link differently when on an img than
> when on an a. But there is no hint as to how that can be done.

I don't think this supports your argument. First, how to expose a link,
while not explicitly specified, seems to be pretty well understood by
browser developers in a great variety of circumstances - voice output,
list of links, on screen, etc etc.

The only difference called for is the case when you effectively have one
link inside another. I don't think this is more tha  pointing out a clear
issue - that if you merely overload the normal link activation, you will
lose one or other mechanism.

> For a developer to come up with a solution to this is almost
> impossible, when even accessibility tools haven't come up with a good
> solution. They look at it, see the problem, weight up how important it
> is in comparison to other work they need to do and move on. Can you
> blame them?

I think this is a misrepresentation. 3 independent screen readers that I
believe between them represent a significant market share have all come up
with an implementation.

iCab used a special cursor to provide a visual indication that a longdesc
was present (at the time they implemented I believe there was no screen
reader for Mac - it was before VoiceOver and after people stopped making
commerical add-on screen readers for the platform). In TellMeMore I
introduced a notification in the Browser UI - and oddly enough when
thinking of an update to the extension recently I was looking at the idea
of adding the indicator in the address bar (minor cosmetic difference to
what I already do - which is determined in part by the limitiations of
what I could do without any serious change to Opera).

In passing, I note that Opera's implemenation, showing the content of the
attribute in a slightly harder-to-use form, was designed to provide a
user-oriented remediation for the most common error by people using
longdesc (as determined by some research I did at the time - although I
can't provide the data to do a proper longitudinal study), at the same
time trying to steer people who did test in the right direction.

Maciej claimed
> The "turn the image around" idea is handwavey to the point of
> uselessness.

I think the idea was reasonably laid out as a suggestion for UI
implementation (whether it would end up being adopted is an open question
- but not one that I think needs an answer in the context of this issue
since there are already implementations strategies that seem viable). I
see the proposal from James to use iframes behind images is basically a
solution-first restatement of the idea. So while Maciej later clarified, I
think this rejection did not reach his usual standard of technical
explanation.

> If we re-introduce it into HTML5, we need to be quite clear about how
> this has to be implemented. Otherwise we will fall into the same trap
> again.

I'm not convinced by that. While some implementations will be better than
others, I think the evidence of the half-dozen-odd independent
implementations that are out there now suggests that people who are
interested in implementing the functionality don't seem to have any
problem making it workable already.

It is important to have implementations that are usable. I don't see
evidence that this is really holding anyone back. It doesn't even seem to
be the block for NVDA - I'd like to have Mick and Jamie's own opinions,
but I would be surprised if they couldn't figure out a user interface for
the feature. My understanding is they don't *want* to implement one, in
partiular because they think the browser should offer something for all
users, not just those with a screen reader, and that is likely to
influence the implementation choices they make.

I would contrast this situation with accesskey implementations, which are
*not* good, and *still* cause problems that make some people reluctant to
support accesskey. Admittedly the advice in the HTML4 spec is worse than
that for longdesc, but the implementation story has mostly one of little
apparent effort to fix things that were obviously broken, meaning that a
decade after Mr Foliot explained why he thought there was a problem, and I
started explaining to him why the problem was a mix of some ill-considered
advice and some too-easy acceptance of that advice. This combined in some
cases I know of, although I don't want to say that this is true of every
implementor, with a reluctance to prioritise any work on the feature.

Whatever the reasons, accesskey in many browsers is still very poorly
implemented. I believe Opera's version is clearly the best, reaching to
the dizzying heights of "not bad when the page was done perfectly right".
Which is not a ringing endorsement. It is hopeless in the face of common
problems that some others like IE managed to solve years ago, and their
solution would work in the context of Opera's accesskey implementation.

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
             chaals@yandex-team.ru         Find more at http://yandex.com

Received on Friday, 21 September 2012 14:04:30 UTC