Re: ISSUE-30 (Longdesc) Change Proposal

Jonas Sicking On 09-10-27 02.44:

> On Mon, Oct 26, 2009 at 3:51 PM, Leif Halvard Silli
>> Jonas Sicking On 09-10-26 22.55:

    [...]

>> However, as the rest of my letter hinted, @longdesc and aria-describedby are
>> different. @longdesc has a much more fixed behavior than aria-describedby
>> has - and is much more single purposed than aria-describedby. See the other
>> replies in this thread. The primary specialty of longdesc is simply that it
>> is only meant for IMG, FRAME and IFRAME - the rest of its inherited behavior
>> follows from that.
> 
> I agree that @longdesc and @aria-describedby aren't exactly the same.
> However they are very similar.


Everything with a link is "similar". But normally, if one element 
can take IDREFS only and another can take a single, complete URI, 
only, then we don't consider them similar.

> They were both designed to solve the
> problem: "provide a description for an element". The only differences
> that I see is that @longdesc only solves the problem for a small set
> of elements.

That's one difference, yes.  Though we should probably extend 
@longdesc to <video> and <audio> also.

> Also, syntactically @aria-describedby has a larger syntax if the
> description is in an external document.


In addition to require a much more verbose *markup*, there are 
also "expected effect" differences. See John's message [1] (and my 
reply).

[1] http://www.w3.org/mid/009901ca566c$a296a9c0$e7c3fd40$@edu

> I don't know why WAI chose to
> use this syntax rather than that of @longdesc. However I would assume
> that they did consider the @longdesc syntax and felt that the current
> @aria-describedby syntax is superior.


Aria-describedby (and its syntax) is not superior to longdesc (and 
its syntax) any more than aria-labeledby (and its syntax) is 
"superior" to using alt="" (and its "syntax").

ARIA-describedby is very flexible for what it is meant for. E.g. 
it can take several IDREFS and can be placed in any element.

But ARIA generally seems to be oriented at drawing links between 
*visible* parts of a page. Think about the landmark roles.  The 
same goes for aria-describedby, if it points to a anchor, then 
that anchor is meant to be visible.

Yeah, in the spirit of "do not bend over backwards": I think the 
spec should recommend longdesc over hidden anchor elements!

When I said that Charles did not mention ARIA in connection with 
@longdesc then I also had in mind how it "maps" to ARIA. For 
instance, if a IMG *has* a valid @alt text, then it doesn't make 
sense to also use aria-labeledby.  And likewise, if a IMG has a 
valid longdesc, then it doesn't make sense to also use 
aria-describedby.

By the way: many times one may also aria-describedby to point to a 
IMG  which itself has a longdesc:

<p>The <i aria-describedby="#image">diagram</i>
<p><img id="image" longdesc="diagram-description.htm" src=img 
alt="Diagram of something". >

I think this example in itself aptly describes the difference 
between longdesc and aria-describedby.

> Given that, 


Sorry, but I did not buy that argument.

> it seems to me wasteful to have two features with such a
> large overlap. Further it seems like technically @aria-describedby is
> a better technical solution since it's available on all elements. Thus
> the only reason I can see for keeping is if removing support for it
> breaks a lot of web pages.


I have not seen a single argument in your replies that defeats the 
technical benefits and functional uniqueness of @longdesc versus 
aria-describedby.

> From what I understand data doesn't
> indicate that there is a lot of usage out there?

Aria-describedby is even less used, I assume.

> I don't think the fact that "there are several implementations" is a
> good argument for keeping @longdesc. This simply proves that the
> feature can be implemented. However using that as a criterion for
> putting a feature in the spec is IMHO a low bar.

Yet, it seems like a bar that is often used. W.r.t. @longdesc, 
then this is but ONE of the criteria.

>> I think now that we have gotten aria-describedby, we do not need to "bend
>> over backwards" for either of them, but can let each of them have their own
>> specialties.
> 
> Features are not free. There's a significant cost to documenting,
> evangelizing, testing, implementing and QAing a feature. And that's
> just the upfront costs. It's impossible to know what the costs are in
> the future. For example if one UA implements @longdesc wrongly (due to
> a bug or misunderstanding the spec), this can lead to content coming
> to depend on this new behavior. This leads to implementations having
> to reverse-engineer each other and many times more complex behavior.

Very good then that there are rather clear expectations about how 
@longdesc should work. UAs also correspond w.r.t implementation.

> There's also a risk that the feature will get in the way of future
> features due to name collisions or due to feature overlap.
> 
> For what it's worth, I feel the same way about @summary, which is also
> better solved by @aria-describedby.


Regarding hypothetical future collisions: if you can bring in 
@summary here, then perhaps I may bring in @version? Let's debate 
@summary in another thread ...
-- 
leif halvard silli

Received on Tuesday, 27 October 2009 14:10:19 UTC