Re: dropping longdesc attribute

On 22 Jun 2007, at 2104, Denis Boudreau (WebConforme) wrote:

> Evening all,
>
>>> Anyway, what rationale for dropping longdesc?
>>
>> IIRC, the reason for not including it was because very few authors  
>> ever use it and, when it is used, it's not used properly.
>
> OMG, that argument again. Who cares if it's useful. Quickly, let's  
> trash h1 to h6 also - and let's not forget blockquote while we're  
> at it.

I don't think anyone disputes longdesc's theoretical utility. But no  
matter how useful an element is _in theory_ if no one produces  
documents using that element it has no utility _in practice_. The  
issue at hand is to show the utility of longdesc in practice. Again,  
I am not saying that longdesc is useless, only that it's utility has  
not been proven in this forum as of right now.


> Longdesc are essential for screen readers to provide long  
> descriptions for graphics that otherwise could not be described  
> because the nature of their content is just too complicated for a  
> simple alt attribute. This is a crucial feature for the benefit of  
> visually impaired users working with screen readers. Longdesc  
> provides the ONLY mean available to describe, in a non-obtrusive  
> way, the nature of an image in an external file while remaining  
> invisible to typical, unimpaired users and user agents. Screen  
> readers are finally getting it's implementation right and we're  
> dropping it?

A survey showing the support (or absence thereof) for longdesc  
amongst ATs would be very useful. Not everyone in the WG deals with  
AT on a regular basis, and thus the more information provided by  
those who do work with AT regularly, the better for everyone.

Both usage of longdesc in the wild and AT support for the element  
need to be established in order to make a reasonable judgement of  
it's value. If, as you say, ATs have only recently begun to support  
the element, that would go a long way to explaining a lack of usage  
in the wild. Conversely, if ATs have supported the element for a long  
period of time, a lack of usage in the wild would indicate a  
rejection of longdesc by authors. Either way, data on the actual  
usage of longdesc, and data on the actual support for longdesc are  
required before a conclusion can be reached.

If it turns out that longdesc has been rejected by authors, it would  
seem a good idea to discover why. And then to find a way to deliver  
the value of longdesc in a way that authors would actually use. But  
that is entirely academic until we know how widely longdesc is  
actually supported and used.


> Is there a single accessibility feature in HTML that will survive  
> this group? Why is the left hand (html-wg) so bluntly ignoring what  
> the right one (wai-wg) does?
>
>> More research on the issue is welcome.  In particular, evidence of  
>> significant real world usage that provides a practical benefit to  
>> users would be good.
>
> And why should we bother? There has been a lot of efforts made  
> previously by John (Folliot) and others in order to save summary  
> and headers in tables. Still, the draft hasn't backed out one bit  
> on the subject. If that didn't give anything, what will? Lachlan,  
> why wouldn't you, for a change (as John had so eloquently asked  
> previously), provide evidence that this attribute is useless? Those  
> of us who work with screen reader users on a regular basis know  
> that this attribute is extremely relevant when it is used properly.  
> If authors are using it all wrong, then let's educate them instead  
> of slashing into features that significantly contribute to the  
> inclusion of disabled people on the web.

The HTML5 spec has not been written. There exists a draft version  
which is currently being reviewed, but it is not the final version,  
it is only a starting point. That starting point has been described  
as being weak on accessibility, very well, that is why the review  
process exists. The only way the spec can get better is if everyone  
participates in the review and brings their knowledge and experience  
to the table.

That said, when a change is requested the burden of proof falls on  
the requester. And that swings both ways: someone wanting to add  
<longdesc> into the spec faces the same burden of proof as someone  
wanting to take <image>'s @alt out of the spec.

To address your specific point: the @headers issue is still  
unresolved. When the issue is resolved the spec will be updated to  
reflect the WG's decision on the matter. I trust that you would agree  
yo-yoing text in and out of the spec based on which way the  
discussion seems to be leaning at a given point would be a waste of  
the editors' time.


> It's already hard enough for the blind. We don't need to make it  
> even more complicated for them simply because we're too caught up  
> in our own little things to grasp such a simple concept.

I agree completely. I hope you agree that we should examine the  
issues in order to make sure we are actually meeting that goal.

s.