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

Maciej Stachowiak, Sun, 16 Sep 2012 10:12:33 -0700:
> On Sep 16, 2012, at 9:40 AM, Leif Halvard Silli wrote:
>> Maciej Stachowiak, Sun, 16 Sep 2012 08:57:54 -0700:
>>> On Sep 16, 2012, at 3:39 AM, Leif Halvard Silli wrote:
>>>> Maciej Stachowiak, Sat, 15 Sep 2012 21:46:47 -0700:
>>>>> On Sep 15, 2012, at 7:55 PM, Leif Halvard Silli wrote:
>>>>> 
>>>>>> 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) VoiceOver will start to read from the top of the page 
>>>>>> instead of from the section where the particular longdesc was 
>>>>>> situated. 
>>>>>> Something which takes away lots of flexibility with regard to 
>>>>>> longdesc. 
>>>>>> And, in fact, it also impacts regular links as well - it is is real 
>>>>>> hole in VoiceOver and Webkit's elegance.
>>>>> 
>>>>> I would say this is the responsibility of the implementors of iCab, 
>>>>> not WebKit or VoiceOver. There is no native support of any kind for 
>>>>> longdesc in WebKit or in VoiceOver. iCab authors have not reported 
>>>>> any bugs indicating that they are blocked. And it is my belief that 
>>>>> iCab can handle this detail by itself.
>>>> 
>>>> I have forwarded your view to iCab. It is true that iCab works around a 
>>>> few bugs as well as issues that the developer disagrees with. So may be 
>>>> this would be one such issue.
>>>> 
>>>> However - and may be this was not sufficient clear in what I said 
>>>> above: I would say that that bug also affect skip-to links - and all 
>>>> links where it is important that focus is moved to the target. This 
>>>> bug, therefore, is a mayor drawback for Webkit keyboard users.
>>> 
>>> I did comment in the bug - I tentatively think links should get focus 
>>> on click if the user has enabled tabbing to links (or is on a 
>>> platform where you always tab to links). 
>> 
>> This bug? https://bugs.webkit.org/show_bug.cgi?id=17450

> 
> No, the one you actually mentioned (about buttons getting focus on click).

Ok. Thanks for looking at bug 17450 too. The two bugs seem related. (At 
least from a conceptual point of view - that's reason I stumbled upon 
bug 22261 despite that I had intended to find bug 17450.)

>> (I mentioned the wrong bug above.)
>> 
>>> But I think that issue is 
>>> off-topic-for longdesc. Happy to discuss elsewhere if you wish.
>> 
>> I hope you see that there is a number of longdesc techniques that do 
>> not work very well (for unsighted users and for keyboard users) because 
>> of that bug. It doesn't even work well to e.g. replace James’s <iframe> 
>> with a <a> element. The only thing that works (unless you add extra 
>> JavaScript and/or CSS) is to make sure the longdesc resource is a dull, 
>> naked page that contains nothing but the longdesc resource.
> 
> That seems like a totally different bug. I am not sure what it has to 
> do with longdesc though. You may think longdesc is like following a 
> link, but I'm pretty sure the way iCab implements it does not follow 
> the code path for clicking on a link.

What does 'code path' refer to? 

I think 'totally different' is too strong: Using different 
screenreaders, try to visit the longdesc resource *fragment* of the 
demo page that I posted.[1] You will then find:

* that VoiceOver reads the page, from the page top. Thus it reads
  the visually hidden text behind the longdesc resource.
* that by contrast, using IE8 or Firefox, JAWS will read the page title,
  and then jump over the page content and down to the start of the
  longdesc fragment. 
* There is no AT the works [well enough] with it, so I cannot report
  how screenreaders work with Opera.

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

A simple focus test can be performed by visiting the HTML5 spec:[2] 

    a. Search for '2.5.5' with your browser's Find-in-page tool.
       (You will then come to point 2.5.5 in the ToC)
    b. Hit the Esc key (or similar) to get out of Find-in-page modus.
    c. Press Tabulator to move to next link - (2.5.5.1)

Results:
      Safari - first link of the page (Homepage link)
   Chrome - next link (2.5.5.1)
  Firefox - next link (2.5.5.1)
    Opera - first FORM FIELD of the page
W3m textbrowser - next link (2.5.5.1)
      IE8 - next link (2.5.5.1)
                  (Surprising that Chrome was different from 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)
   Chrome - first link of the page (Homepage link)
  Firefox - next link (Link text: 'digits')
    Opera - (may not work at all?)
W3m textbrowser - next link (Link text: 'digits')
      IE8 - first link of the page (Homepage link)

So worse results for the second test. There does not seem to be a 100 
percent correlation between the Find-in-page focus and the link focus.

[1] fragment URL/hash name:
    
http://malform.no/testing/a-demo-of/longdesc-with-hidden-iframe/#longDesc

[2] http://dev.w3.org/html5/spec/

-- 
leif halvard silli

Received on Sunday, 16 September 2012 19:17:02 UTC