Re: My case for the obsoletion of longdesc (Was: 48-Hour Consensus Call: InstateLongdesc CP Update)

Joshue O Connor, Sun, 16 Sep 2012 09:50:55 +0100:
> Leif Halvard Silli wrote:

> I really don't think that was James point. One of the core principles 
> of idea of UD is that there are solutions that can be used without 
> specialist equipment that will work for a wide range of users with 
> diverse abilities. Not that you need to design the AT to fit the 
> proposed solution.

One could argue that @longdesc is not a "wheelchair stair lift" but 
just a normal link. But if we accept the premise: A wheelchair failing 
to work with wheelchair lifts would be a failed wheelchair, regardless 
of curb-cuts would often would be a better design.

>> in that regard: It is OK to argue that something other than @longdesc
>> wold work better. However, due to bug 22261 - "Clicking on a non-text
>> input element does not give it focus",[1] Webkit and Chromium suffers
>> from the following: if one opens a longdesc link (e.g. with Webkit
>> based iCab)
> 
> With all due respect to iCab, I kinda wish people would stop 
> referring to it as some kind of model of best practice.

To hint at something you said the last 48 hours: I am not 'fanatic'. I 
only mentioned iCab because it is a Webkit browser, in order to inform 
about how a bug in Webkit could affect other Webkit browsers - such as 
Safari - that eventually would like to implement @longdesc. 'Cludge' is 
the right word for Webkit's handling of links - in general: It makes 
Webkit quite unsuitable for keyboard navigation where links involved. 
Same page links are also a problem, see Roger Johanson's article from 
earlier this year:

http://www.456bereastreet.com/archive/201203/skip_links_and_other_in_page_links_in_webkit_browsers/

I am really sorry that my reference to iCab was perceive as fanboy-ism 
rather than the technical input it was meant to be.

> I don't know anyone who uses it, 

You also seem unaware of the entire skip links problem in 
Webkit/Chromium. But a more relevant point in our context is: Could 
iCab have been of help to e.g. a VoiceOver user that wanted longdesc 
support? Unfortunately not. If it *had* been working, the my bet is 
that you would have known someone who used it.

[ snip ]

> and just because it has some cludge for handling @longdesc

That 'cludge', as you call it, is the exact same way that JAWS works 
with longdesc - there is no difference. (If there is, then I'd like to 
hear about it.) And it is also the the exact same way that Firefox has 
done it when they implemented longdesc support via aria-describedby.[1] 
However, if you read my letter to the bottom, then you would have seen 
that I think the last week's improvements to the HTML5 spec, allows for 
a - I don't know - less 'cludgy' way to implement longdesc.

[1] 
http://asurkov.blogspot.co.uk/2012/05/firefox-14-whats-new-for-at-developers.html#c5196273056475151691
-- 
leif halvard silli

Received on Sunday, 16 September 2012 11:21:54 UTC