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

On Sep 16, 2012, at 12:16 PM, Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote:

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

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.

> 
> 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. VoiceOver reads based on the VoiceOver cursor, not the keyboard focus.

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

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

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

Regards,
Maciej

Received on Sunday, 16 September 2012 19:41:08 UTC