Default tab order (was: Using ARIA to override semantics)

> However, perhaps the spec needs to *specify* that it must belong in the 
> default tab order? Thoughts? 

Discussing with myself: There are several groups of keyboard operated 
user agents that could need that the spec told them to - or whether to 
- include @longdesc and @cite in the default tab order (so that they 
subsequently could make these URLs available to the user):

    * screen readers
    * text browsers (Lynx et co)
    * Vimperator (VIM-like Firefox mod http://vimperator.org/vimperator)

Leif H S

Leif Halvard Silli, Tue, 22 Mar 2011 08:32:44 +0100:
> Steve Faulkner, Mon, 21 Mar 2011 15:20:04 -0700:
> 
>> i agree that the presence of a longdes should not make the element
>> interactive, what has been requested by a screen reader vendor is that
>> in the case of longdesc being accessed via a context menu the presence
>> of longdesc will cause the image to be inlcuded in the default tab
>> order. This is so that users can access the context menu and would be
>> required for keyboard users in general to be able to access the
>> context menu.
> 
> According to HTML5, default inclusion in the tab order is not decided 
> by whether it is interactive but by 'platform conventions': [1] 
> 
> ]] If the attribute is omitted or parsing the value returns an error
>       The user agent should follow platform conventions to determine
>       if the element is to be focusable and, if so, whether the 
>       element can be reached using sequential focus navigation, and
>       if so, what its relative order should be. [[
> 
> [1] 
> 
http://dev.w3.org/html5/spec/editing#sequential-focus-navigation-and-the-tabindex-attribute
> 
> However, perhaps the spec needs to *specify* that it must belong in the 
> default tab order? Thoughts? 
> 
> And, btw, what about @cite? @cite is only accessible via context menu, 
> AFAIK. This is also, in my view, an issue for text browsers like Lynx. 
> (Text browsers could have implemented support for @longdesc and @cite 
> in a fashion similar to how they implement support for image maps: for 
> image maps one must "walk into" the image to retrieve the list of links 
> of the image map.)

Received on Tuesday, 22 March 2011 08:11:40 UTC