Re: Keyboard Behaviors for Elements with Role "Grid"

The tricky part here is discoverability. If I want to edit a cell and 
I'm just trying things (which is how most people figure out 
applications) I'll probably not think to try shift down and up arrow to 
dive into and surface out of a container. Mac folks are trained to do 
this with control+alt+up/down as it is a commonly used gesture in Voice 
Over, but it would be quite unfamiliar to everybody else. That said, 
there is a whole pandora's box around how people should discover 
keyboard controls in general so if we felt more comfortable with that 
being a solved problem maybe I'd be less hesitant to use more esoteric 
key combinations.

CB

James Craig wrote:
>
> Chris Blouch wrote:
>
>> The next hurdle would be to edit a cell. If we are already using 
>> arrows to navigate the grid how do we handle the overloading to 
>> navigate within a cell? I suggest that once the user starts typing 
>> alphanumeric characters they are now in "edit mode"  or have chosen 
>> to "interact with", in Apple Voice Over parlance, that particular 
>> cell. Maybe there should be an extra key to interact but the 
>> alphanumeric trigger could be sufficient. Once in edit mode the 
>> arrows move through the cell content instead of the grid content. 
>> Once editing is completed the user would need to get out of edit 
>> mode. I would suggest Enter as a reasonable key that users might try. 
>> One objection is that enter is often the submit function, but this 
>> can be overridden and should be when in edit mode. This could be a 
>> bit tricky if the grid cell content actually contains more widgets so 
>> I would suggest that when the user is "interacting with" a cell, tab 
>> and other general navigation become active but are constrained to 
>> items within the cell until they stop interacting with that cell.
>
> The idea of "interacting with" a sub-level ARIA widget solves a lot of 
> complexity problems. In my opinion though, Enter and its counterpart, 
> Escape, should be reserved for primary actions such as confirming or 
> canceling forms and dialogs.
>
> What about:
>
>    Shift + Down Arrow to "interact with" a sub-level item.
>    Shift + Up Arrow to "stop interacting with" a sub-level item.
>
>    Shift + Right Arrow to navigate to the next non-read-only item/cell 
> in the list/grid.
>    Shift + Left Arrow to navigate to the previous non-read-only 
> item/cell in the list/grid.
>
> Unlike the other modifier keys (control, alt, option, command, 
> windows), shift if pretty consistent across browsers and platforms, 
> and is rarely reserved by the browser. The only place I can see where 
> this would cause trouble is with text selection using arrow keys, and 
> ARIA widgets are already intercepting those arrow keys anyway.
>
>

Received on Tuesday, 29 July 2008 18:51:43 UTC