Re: Keyboard Behaviors for Elements with Role "Grid"

Continuing from today's DHTML style guide discussion, it seems like we 
have an issue with overloading of the tab key when it comes to grids. In 
our ideal world we want consistency in that the user can tab to a 
widget, use other keys to interact with that widget and then tab to get 
out. Maintaining this object action binding becomes difficult when the 
widget is a grid because there is some user expectation that they should 
be able to tab within cells of the grid. I propose that if we can give 
up on using tab within the grid we can come to a nice compromise between 
user expectations and usability. If we can keep the tab just for moving 
between widgets a user might tab to a grid and then hit tab again 
expecting to move withing grid cells but instead they get moved to 
another widget. So their next experiment would probably be to shift-tab 
back to the widget and then use the arrows to move around and they would 
be rewarded with success.

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.

I know there are a number of compromises in the above proposal and I 
probably missed some gotchas, but it feels like other avenues are 
fraught with greater degrees of ambiguous key behavior overloading, lack 
of discoverability or inconsistency with existing expected behaviors.

Hope this helps.

CB


James Craig wrote:
>
> Why not just let the left and right arrow keys wrap in a grid? (e.g. 
> Pressing right arrow on the last cell of a row would wrap to the first 
> cell of the next row. Also, left arrow would wrap 'up' a row.)
>
> I think we should avoid defining modifier keys whenever we can, 
> because of browser and cross-platform implications.
>
> James
>
>
>
> On Jul 29, 2008, at 8:39 AM, Joseph Scheuhammer <clown@utoronto.ca> 
> wrote:
>
>>
>> Dave Pawson wrote:
>>
>>> If moving in a grid structure - with sideways and up/down movement 
>>> possible
>>> wouldn't the arrow keys be a more natural mapping?
>>>
>>> Control + an arrow key?
>>>
>>> Just a suggestion.
>>>
>>> regards
>>>
>>>
>>>
>>>
>>> -- Dave Pawson XSLT XSL-FO FAQ. http://www.dpawson.co.uk
>> I'm not wedded to Ctrl+Tab, so ctrl+arrow keys may be the way to go.  
>> But, again, I wouldn't be surprised if the OS or some browser is 
>> already using that key combo.
>>
>> -- 
>> ;;;;joseph
>>
>> 'This is not war -- this is pest control!'
>>     - "Doomsday", Dalek Leader -
>>
>>
>

Received on Tuesday, 29 July 2008 17:31:28 UTC