Re: Drop longdesc, get aria-describedat?

Laura Carlson, Thu, 8 Mar 2012 12:06:52 -0600:

First off: Steve yesterday confirmed that Internet Explorer's longdesc 
implementation is plain wrong: It treats the URL as text string. Thus 
it implements it precisely the way the WHATWG blog once ridiculed the 
@longdesc usage for.  See this bug:  
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16268

Now to this discussion:

>> "obsolete but conforming. That clearly signals that a replacement is 
expected
>> while providing needed functionality right away

>> I  find that to be an acceptable compromise.

> 1. Regarding conforming but with a warning the HTML Chairs' Decision
> on ISSUE-30, stated:
> "The weakest proposal was the one that makes longdesc conforming but
> with a warning...there was a strong argument which is unique to this
> proposal: if longdesc is conforming, user agents will be required to
> support it; if there is a validator warning, users will be discouraged
> from using it. This combination is the worst of all possibilities.
> Eliminating this proposal early made the process of coming to a
> resolution simpler." [1]

Thanks. I too had that statement in mind. And I have several times said 
the exact same thing as you.  However, in April 2011, Sam said: 

]] The general thrust I gather from these minutes is "we need more time 
to 
properly deprecate longdesc".  If that indeed is the case, then back 
that claim up with specifics.  WHO needs more time?  How much time 
would 
they LIKE?  How much time could they LIVE WITH?  What would be the 
IMPACT in terms of negative effects if they were not provided that 
time? [[

http://lists.w3.org/Archives/Public/public-html-a11y/2011Apr/0181.html

And so: If new info emerges, then evaluation of previous decisions can 
change. That's the whole point with the reevaluation process we now are 
having. And in that regard, it is new info that people are discussing a 
replacement attribute - aria-describedAT, an attribute which would be 
global and not only limited to <img>. The chairs have more than once 
asked why only <img> needs @longdesc - and do in general seem to favor 
'general' solutions - for better or worse.

Now, the reason why the chairs brushed 'conforming but with a warning'  
- which, btw, *isn't* the exact same as 'conforming but with a 
warning'! -  had to do with two things: Vendors must implement 
@longdesc, and authors should not use it.

However, the 'obsolete but conforming' status, in contrast, would put 
significantly less burden on vendors, simply because it would be 
understood that we are moving away from @longdesc - it is just for 
transition that we need it. And that's why - coupled with Sam's quote 
above - I find it likely that they *now* would evaluate a call for 
'obsolete but conforming' status different from how they evaluated 
'conforming but with a warning' back then.

Of course, vendors would still be free to implement it. But one could 
not really expect that those vendors that haven't implemented @longdesc 
until now, would start to implement @longdesc just because it became 
obsolete but conforming?! They would rather focus on implementing 
@longdesc's replacement feature.
-- 
Leif Halvard Silli

Received on Friday, 9 March 2012 01:49:56 UTC