Re: dropping longdesc attribute

Could I get a link to a couple live pages using longdesc properly?


On 6/23/07 12:01 AM, "scott lewis" <sfl@scotfl.ca> wrote:

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

-- 
::   thyme online ltd
::   po box cb13650  nassau  the bahamas
::   website: http://www.thymeonline.com/
::   tel: 242 327-1864  fax: 242 377 1038

Received on Monday, 25 June 2007 16:28:39 UTC