Re: ISSUE-30 (Longdesc) Change Proposal

On Tue, Oct 27, 2009 at 2:06 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Jonas Sicking wrote:
>>
>> I don't agree there's an expected difference.
>>
>> Comparing the markups:
>>
>> <img aria-describedby="desc">
>> <a href="description.html" id="desc">...</a>
>>
>> and
>>
>> <img longdesc="description.html">
>
>
> ...Right, the first example has an explicit link *on the same page* as the
> image, which IMHO is an unrealistic expectation given other 'design'
> considerations that a content developer might have to juggle, while the
> second (longdesc) example does not.  The fact that even you provided
> 'different' examples in illustrating your point shows that there is a huge
> difference.

Huh? I used two different examples to show that two different features
are in fact equivalent.

> I have already pointed to one example earlier in this thread
> (http://lists.w3.org/Archives/Public/public-html/2009Oct/0951.html) where
> the designer explicitly does not want a URL included on screen, and is in
> fact using CSS to position the link off screen.  Meanwhile the longdesc
> provides the same URL, but is not visible on screen, so the 'expected'
> difference is significant: one you see the link, one you don't see the
> link. You can argue all you want that putting a visible link to a longer
> description on the same page as a complex image is "better" for all
> accessibility, and you would be right, except that it is unrealistic to
> expect that to happen all the time - longdesc is a mechanism for when that
> 'better' option is not available.

Ah, I guess I misunderstood what you were arguing was different
between the two features. I agree we can't always expect authors to
put a visible link to accessibility data on the page. Fortunately
HTML5 already has a means to deal with this. I'll adjust my examples:

<img aria-describedby="desc">
<a href="description.html" id="desc" hidden>...</a>

is equivalent to

<img longdesc="description.html">


> Finally, I am somewhat at a loss as to why there is resistance to
> improving (or in this case, maintaining) the developer's toolbox with
> specialty tools.  The cost to browser developers is minimal to zero, the
> cost to content creators is a non-issue, AT support exists today and the
> benefit (when applied) has significant enough value to preserve the
> intent.  What 'value', exactly, do we receive by obsolescing the longdesc
> attribute?

Contrary to what many people seem to believe, at least at mozilla we
don't just care about what the cost is to develop our browser, but
also what is good for the web.

As I illustrated in previous emails in this thread, adding features
does not just come with benefits. It comes with significant costs to
all parties involved. For example not having a clear simple message to
web authors about how to provide a description for an element, I
strongly believe, means that fewer people will do the right thing in
providing such a description.

The value we receive by obsoleting the longdesc attribute include:
* Smaller HTML5 spec
* Clearer message to authors for how to make their pages accessible
* Simpler AT tools
* Simpler browsers
* Simpler validators
* Smaller risks that bugs will make the feature more complex in the
future (HTML parsing started so simple, have you seen what a complex
mess it is today due partially to bugs that people came to depend on)
* Less time spent on creating a test suite (or if you spend the same
amount of time: better test suite)
* Smaller risk that authors will conflicting data in the two attributes
* Less time for authors to learn how to make a site accessible

In short, the same benefit you get from removing any redundant
feature. The question should never be "why not have this feature in
the spec", the question should always be "why should we have this
feature in the spec".

/ Jonas

Received on Tuesday, 27 October 2009 21:57:52 UTC