The point of the following is to open the discussion on keyboard-only access with respect to the grid. The main topics are navigation, keyboard focus, headers, and selections. This was written before looking at the grid's code or test files in order that I not be influenced by how the grid currently implements keyboard access. Since then, I've started to look at the gird in detail, and it looks to function close to what I've described. In that regard, is there a document that describes the keyboard "rules" for grid?

Outline

• Navigation
• Keyboard Focus
• Column Headers
• Selections

Navigation

Keyboard navigation is as follows (taken from the DHTML style guide section on tables, specifically the sub-section on standard tables [http://dev.aol.com/dhtml_style_guide#table]:

Keys for Standard Tables

• Tab
• The initial tab enters the grid with focus on the first header cell.
• Once in the grid a second tab moves out of the grid to the next tab stop.
• Once focus is established in the grid, a TAB into or a Shift Tab into the grid will return to the cell which last had focus.
• Left and Right Arrow Navigation between columns. If the next cell in the row is empty, focus should not move.
• Up and Down Arrow Navigation between Rows. If the next cell in the column is empty, focus should move to the first column in the next row. If the next cell in the column is not empty, focus should move directly to that cell

(Aside: the rules for "empty" cells is controversial. They are ignored in what follows).

Keyboard Focus

There is a general focus issue, namely, what has focus in a grid?

One possibility is to model grid after toolbar [http://dev.aol.com/dhtml_style_guide#toolbar] then the grid itself keeps focus, and the key presses are handled by the grid. As the user arrows from cell to cell, the key strokes are handled by the grid, and it styles the cell to make it appear focussed/selected.

Another scenario has individual cells obtaining focus as the user arrows among them. This is implied by the style guide quoted above (Keys for Standard Tables). It is also how the dijit colour palette widget works.

Note, however, that the contents of the cell introduces a wrinkle. If the cell contents is "data", and rendered as read-only text, then either of the above models will suffice. But, if the cell contains a widget or a hyperlink, then there are advantages if focus was on that widget. For the sake of discussion, when cell contents is a widget or a hyperlink, it is referred to here as "interactive content":

1. If focus is on the interactive content, keyboard interaction with that content is already defined by the widget. For example, if the content is a hyperlink, then pressing <enter> will activate the link. If a checkbox, <space> will check or uncheck it. If a menu, the menu can be popped open, and navigated.
2. Users will not readily see a distinction between a cell and, say, the checkbox inside it. They are apt to see the interactive content as the thing that has focus. If focus remains on the cell itself, then a keystroke is needed to move focus (in)to the interactive content, and another to move back up to the cell. Users will find this awkward (admittedly an armchair hypothesis).

One exception is where the cell's content is editable text. Here, initially, focus is on the cell. If enter is pressed, then the field becomes an editable text field, gains focus, and the keystrokes for a text field come into play. Note that text field could involve auto-completion with a popup of suggested values. Users confirm the final value with a <return>, the cell reverts to static text with the new value, and focus is once again on the cell. (Note: desktop spreadsheets do not behave this way. If a cell is editable, once focus is brought to it, one can add content to it. Pressing enter accepts the new value and moves focus to the cell immediately below).

There is a disadvantage with putting the focus on interactive content, namely, how does one navigate to another cell if the interactive content already handles arrow keystrokes. For example, if the cell contains a slider, left and right arrows are for moving the slider thumb, not for moving to the previous/next cell. There needs to be a way to move focus back up to the cell.

Column Headers

There is a need to inform user via a keystroke which column and row they are in when they have navigated to a particular cell. This includes any headers associated with the column and row.

Users also require quick navigation via a keystroke to the column headers. That is, no matter what cell the user is currrently in, they can move quickly to the top of the column. Similarly for navigating quickly to the beginning and end of the current row. I suggest <home> to move keyboard focus to the column header (meaning, "move to the top of the column"), and

Selections

When focus is on a cell, it is automatically "selected" as well.

There needs to be a keystroke to select the current row or column, but I have no suggestion yet.

After selecting a cell, extend the selection to neighbouring cells using <shift+arrow>.

Once there is a selection, it can be cut or copied using the usual keystrokes. Users may then move to another location in the grid, and paste the cut/copied cells.

Unfortunately, the keystrokes for extending the selection, cut, copy, and paste all potentially conflict with the focus rules above regarding interactive content, since that content itself may use these keystrokes when it has focus. It suggests that one needs to put focus on the cell, not on its contents. Nonetheless, the selection keystrokes could work if the interactive content has no handler for <shift+arrow>, which could then bubble up to the cell itself, where it would be detected as meaning "extend to selection of cells".