W3C home > Mailing lists > Public > www-archive@w3.org > September 2012

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

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Sun, 16 Sep 2012 22:41:53 +0200
To: Maciej Stachowiak <mjs@apple.com>
Cc: "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <20120916224153884096.efa72e50@xn--mlform-iua.no>
Maciej Stachowiak, Sun, 16 Sep 2012 12:40:39 -0700:
> On Sep 16, 2012, at 12:16 PM, Leif Halvard Silli wrote:

>> * that VoiceOver reads the page, from the page top. Thus it reads
>>  the visually hidden text behind the longdesc resource.

> The behavior you observe may be similar, but the underlying mechanism 
> is totally different. I am pretty confident that fixing the bug you 
> mention will have no effect whatsoever on iCab's implementation of 
> longdesc.

Effect on which angle of iCab's longdesc implementation? If you meant 
to say that fixing bug 17450 is not going to improve the way VoiceOver 
behave with iCab, then I could imagine that it is so ... 

But it is also matter of defining what to expect, conceptually, even if 
that concept has to be solved via multiple bugs for more or less, on 
the surface, parallel features. Both the Devil and the consumer wants 
more: Give him Find-in-Page focus, and he wants Follow-link focus too, 
because they logically belongs together.

>> On ironic detail w.r.t. VoiceOver is that it *stops* reading at the 
>> bottom of the focused fragment (this is due to the CSS). The irony 
>> being that it respects the *end* of the focus, but not the beginning of 
>> it ...
> 
> I am not sure if you understand how focus works in our engine or how 
> VoiceOver relates to focus.

To the first: What is it you suspect I don't understand w.r.t. focus in 
Webkit? To the second: It might very well be. Though I may understand 
more than A11Y TF members with a Windows only background do, my 
VoiceOver usage is probably simplistic.

> VoiceOver reads based on the VoiceOver cursor, not the keyboard focus.

Would the VO cursor be that what I see in that "black bar" at the 
bottom of the page? 

But if a VoiceOver user activates a same-page-link, should he/she not 
expect that VO start to read from the target? Has Roger Johansson not 
got it when he complains about skip to links not functioning? Would it 
not help VO users if the skip-to links problem was fixed?

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

> Find in Page does not give keyboard focus to what you find in Safari.

>> Another test:
>> 
>> a. Follow a fragment link to the middle of a page
>>   http://dev.w3.org/html5/spec/common-microsyntaxes.html#yearless-dates
>> b. Press Tabulator to move to next link
>> 
>> Results - the link that get chosen:
>> 	     Safari - first link of the page (Homepage link)

> Nor does fragment navigation - that's the bug you cited.

And getting it would not help VO users? Btw, I seem to remember seeing 
James (Craig) follow up on a bug related to focus in HTML5.
-- 
leif halvard silli
Received on Sunday, 16 September 2012 20:42:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:18:57 GMT