W3C home > Mailing lists > Public > wai-xtech@w3.org > July 2008

Re: Keyboard Behaviors for Elements with Role "Grid"

From: James Craig <jcraig@apple.com>
Date: Tue, 29 Jul 2008 11:34:25 -0700
Message-Id: <3CEB861B-B5D9-451B-87C3-8332E5F089AC@apple.com>
To: W3C WAI-XTECH <wai-xtech@w3.org>

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:35:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:53 GMT