W3C home > Mailing lists > Public > public-html-a11y@w3.org > September 2012

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

From: Joshue O Connor <joshue.oconnor@cfit.ie>
Date: Mon, 17 Sep 2012 08:51:40 +0100
Message-ID: <5056D68C.1040904@cfit.ie>
To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
CC: James Craig <jcraig@apple.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, HTML Accessibility Task Force <public-html-a11y@w3.org>, w3c-wai-pf@w3.org
Leif Halvard Silli wrote:
[...]
> 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.

Not at all Leif. I understand why you site it as an example.

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

TBH, I'm not impressed with the SR implementation and would like us to 
provide a solution that moves beyond it. I like the idea of the 
@longdesc being 'buffered' by the SR and called on a user defined 
keystroke if required.

I also like the idea of @longdesc being automatically read on focus 
(after any other important link info was read etc) and then stopped on 
any other keypress. Rather like the way that aria-describedby is 
currently implemented. I think that is elegant.

Cheers

Josh
Received on Monday, 17 September 2012 07:52:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 17 September 2012 07:52:18 GMT