Re: Keyboard Behaviors for Elements with Role "Grid"

Dear John,

I suggest the following keyboard interaction pattern:
1. Tab and shift + tab move a user in and out of a grid.

2. Left, right, up and down arrows allow a user to traverse the cells of a 
grid.

3. Pushing enter on a cell switch the mode to edit mode and pushing enter 
again switch the mode back to navigation mode.

The concept of an edit mode and navigation mode currently exists in screen 
readers eg. when interacting with a web page, Jaws allows a user to navigate 
the web page in a mode called the virtual cursor mode (aka navigation mode), 
and pushing enter on any form field switches the mode to Forms mode (aka 
edit mode).

I know pushing enter has the unavoidable problem of terminating a dialog box 
sometimes (equates to clicking the ok button essentially), perhaps another 
key could be associated to the mode toggle function?

Cheers,
kenny.
 ----- Original Message ----- 
From: "Jon Gunderson" <jongund@illinois.edu>
To: "Schnabel, Stefan" <stefan.schnabel@sap.com>; "Evans, Donald" 
<Donald.Evans@corp.aol.com>; "Richard Schwerdtfeger" <schwer@us.ibm.com>; 
<wai-xtech@w3.org>; <wai-xtech-request@w3.org>
Cc: "Schaus, Martin" <martin.schaus@sap.com>; "Grigoriadis, Georgios" 
<georgios.grigoriadis@sap.com>; "Keim, Oliver" <oliver.keim@sap.com>; "Aaron 
M Leventhal" <aleventh@us.ibm.com>
Sent: Friday, July 11, 2008 11:50 PM
Subject: Re: Keyboard Behaviors for Elements with Role "Grid"



Using tab for cell navigation is very poor for usability.  This will force 
keyboard only users to have tab maybe several hundred times to get to the 
"gridcell" they want to edit.

I also think that all cells, including read only cells, in a grid should be 
part of the grid navigation.  Otherwise it will be very confusing to screen 
reader users, who will probably miss a lot of read only content, or not 
understand how to move between interactive content and read only content.

Jon

---- Original message ----
>Date: Fri, 11 Jul 2008 12:17:45 +0200
>From: "Schnabel, Stefan" <stefan.schnabel@sap.com>
>Subject: Keyboard  Behaviors for Elements with Role "Grid"
>To: "Evans, Donald" <Donald.Evans@corp.aol.com>, "Richard Schwerdtfeger" 
><schwer@us.ibm.com>, <wai-xtech@w3.org>, <wai-xtech-request@w3.org>
>Cc: "Schaus, Martin" <martin.schaus@sap.com>, "Grigoriadis, Georgios" 
><georgios.grigoriadis@sap.com>, "Keim, Oliver" <oliver.keim@sap.com>, 
>"Aaron M Leventhal" <aleventh@us.ibm.com>
>
>   Hi Don, Rich,
>
>   As a result of last F2F, Martin Schaus requested me
>   to send you more info regarding keyboard navigation
>   within read-only grids and grids that do contain
>   other active elements in their grid cells.
>
>   Please find below the concepts and keys used for
>   keyboard navigation within an element with role
>   "grid" (not: table!) as we @ SAP understand it (in
>   the style of the
>   http://dev.aol.com/dhtml_style_guide site).
>
>   In addition, I suggest to
>
>   a) rename "25.Tables" to "Grid" in the dhtml style
>   guide page
>
>   b) merge content of 28. Tree Grid into the "Grid"
>   section
>
>   c) include example images appropriately
>
>   In case of questions, do not hesitate to contact me.
>
>   I'll try to catch the next Tuesday meeting (on 15th)
>   for a in-depth discussion.
>
>   Best Regards
>
>   Stefan
>
>   Concepts
>
>   Table -> basically HTML Table element, Purely for
>   Layout with role:presentation
>
>   Grid
>
>        * Contains always potentially editable content
>        * Cell content may be read-only OR editable (!)
>
>   1) We have a discrepancy in understanding how TAB
>   should be used within grids.
>
>        * The group originally intended TAB to be used
>          as SKIPPING key (entering-leaving grid,
>          restoring focus in last focused cell in
>          grid). This comes from a picture in mind
>          having a grid as an entity of non editable
>          (read-only) cells.
>
>        * Reality in business apps: We @ SAP have MANY
>          editable grids and using TAB for cell
>          navigation within a grid row between editable
>          cells and cells that are hosting other
>          elements within.
>
>        * As a consequence, TAB cannot be used anymore
>          to skip grids. This in turn requires the
>          definition of an EXTRA skipping key
>          combination (Ctrl+Tab, see below) to leave
>          the grid or return to the last focused
>          position within the grid.
>
>     2) We believe that also the information that a
>     cell is empty may be a valuable information,
>     hence, also empty grid cells should be focusable
>     with arrow keys (This setting should be
>     configurable, with default=on). However, TAB key
>     should skip read-only grid cells always (reason:
>     fast data entry). Editable empty cells are also
>     focused with TAB.
>
>     3) We need to define keyboard behaviors to
>     switch/activate cells in editable state (if
>     allowed by application).
>
>     In initial state, all cells of a grid are
>     potentially read-only and are navigated using
>     either arrow or tab keys. Visual and AT info
>     indicates the user when focusing a cell that it is
>     potentially editable. Now we have to activate the
>     edit mode of the cell.
>
>     We distinguish here between a) Explicit Activation
>     and b) Implicit Activation.
>
>     Explicit activation uses a function key (F2) when
>     focus is on the editable cell (NOT Enter, this is
>     reserved for function and not for activation
>     triggering!). Pressing F2 will activate content
>     for editing and bring caret into editable cell
>     content and there we go.
>
>     Implicit activation is a fine way for fast data
>     entry. When on an editable cell, pressing any
>     alphanumeric key will bring cell into edit mode.
>
>     Tab in both cases will exit edit mode and will
>     focus next cell in the row. (Note: If this cell is
>     editable, too, then TAB may activate ALSO the edit
>     mode of THAT cell. This may be configurable in
>     settings).
>
>     4) Finally, it should be clearly denoted that for
>     editable UI elements embedded inside a grid the
>     inner-element keyboard navigation will (and has
>     to) supersede the grid navigation in certain
>     cases!
>
>     Example: An input element within a grid. When in
>     edit mode, arrow keys move caret within the
>     element instead of to next cell. This should
>     happen naturally and without the need to invoke
>     special AT modes. Tab leaves always the cell at
>     end of edit process.
>
>     5) Please find below the consolidated key mapping
>     proposal according to the concept:
>
>     Basic Grids
>
>     Entry of Grid (enter grid in forward/backward
>     direction):
>
>     Tab/Shift+Tab
>
>        * The initial tab/Shift-Tab enters the grid
>          with focus on the entire grid body.
>        * Once in the grid a second tab moves focus to
>          the first header cell (forward entry,
>          shift-tab respectively focuses last grid
>          cell)
>        * Tab/Shift-Tab within a grid will always move
>          the focus between cells in a grid row
>        * Tab/Shift-Tab within a grid will always move
>          the focus between cells in a grid row
>
>   Fast Exit of Grid (Skipping):
>
>   Ctrl+Tab/Shift+Ctrl+Tab
>
>        * Ctrl+Tab press when in Grid: Focus will be
>          moved to the next focusable element after the
>          grid.
>        * Shift+Ctrl+Tab press when in Grid: Focus will
>          be moved to the previous focusable element
>          before the grid. The focus is restored at the
>          position where the focus was before the grid
>          has lost focus.
>        * Note: it may be necessary dependant on UA
>          (and UA versions!) to implement another
>          skipping key combination
>
>   Navigation within Grid:
>
>   Left and Right Arrow
>
>        * Navigation between editable and read-only
>          cells of a row within columns.
>
>     Up and Down Arrow
>
>        * Navigation between editable and read-only
>          cells within a single grid column.
>        * Simple Scrolling within Grid: When number of
>          rows > visible row count: next/previous data
>          row will be displayed
>
>   Home and End
>
>        * Home focuses the first editable column of the
>          currently focused row
>        * End focuses the last editable column of the
>          currently focused row
>
>   Large Scrolling/Paging within Grid (for large data
>   sets):
>
>   PageUp/PageDown
>
>   -       Navigates to the next/previous set of rows
>   to be displayed within the grid viewport (visible
>   rows)
>
>   Ctrl+HOME/Ctrl+END
>
>   -       Navigates to the first/last set of rows to
>   be displayed within the grid viewport (visible rows)
>
>   When paging through sets of rows the last shown row
>   should become the first row shown when paging on
>   next page and the first shown row should become the
>   last shown row when paging to the previous page.
>
>   An open question is how to display the last sets
>   within the table's viewport:
>   Alternative 1: Showing the last row on the last
>   visible rows automatically changes the paging
>   behavior (offset is changed).
>   Alternative 2: Showing fewer number of rows and
>   having a number of empty columns to NOT change the
>   offset for paging.
>
>   Editable Grid Cell Activation:
>
>   FX (e.g. F2)
>
>        * Explicit Activation. Pressing F2 activates
>          content for editing and bring caret into
>          editable cell.
>        * Note: Dependant on application and UA
>          constrains, it may be necessary to define a
>          different function key
>
>   Any alphanumeric key
>
>        * Implicit Activation. When on an editable
>          cell, pressing any alphanumeric key will
>          bring cell into edit mode.
>
>     --- Grid
> 
> Variants-------------------------------------------------------------------------
>
>     Grids with Headers containing special
>     functionality (e.g row sort functions)
>
>        * All of the keys used by the basic grid above.
>        * No separate tab stop for special
>          functionality icon, the entire header content
>          (boundary rectangle) should be focused
>
>   SPACE
>
>        * Triggers functionality of header cell
>        * For multiple functionality (e.g. Search
>          orders): Pressing Space multiple times
>          toggles or browses+activates within multiple
>          options
>        * Functionality should be persisted in context
>          menu of header cell also (to open, the
>          Shift+F10 of IE may do the job)
>
>   Grids with Multi-Level-Headers
>
>        * All of the keys used by the basic grid above.
>        * Note: AT should announce nested headers.
>
>   Grids with Common Cell Sections
>
>        * All of the keys used by the basic grid above.
>        * Note: In addition, the sub rows remain
>          selectable and the sub row cells remain
>          focusable.
>        * Note: Each cell in a section should contain
>          the same information as the first cell for
>          the Screen Reader. A tool tip may accomplish
>          this purpose.
>
>   Tree Grids
>
>        * All of the keys used by the basic grid above.
>          In addition:
>
>     Control and +/- or Num Pad and +/-
>
>        * Expand or collapse rows when focus is within
>          cell with expand indicator.
>        * Note: The Num Pad +/- conflicts with Jaws
>          commands. There are workarounds available for
>          this within Jaws.
>
>   Embedded Elements in Grids
>
>   ALT combinations:
>
>   -       Alt+Cursor keys are not used at all.
>
>   -       Alt+(Up/Down) is used for control-based
>   navigation (such as opening combo boxes in a
>   table/grid context)
>
>   -       Alt+(Left/Right) for browsing in the global
>   scope of the internet browser main window.
>
>   Dr. Stefan Schnabel
>   Accessibility Expert
>   User Experience - Accessibility
>
>   SAP AG
>   Dietmar-Hopp-Allee 16,
>
>   69190 Walldorf, Germany
>
>   T: +49 (6227) 7-65652
>   F: +49 (6227) 78-29877
>
>   mailto:stefan.schnabel@sap.com
>
>   W:  www.sap.com;  http://www.sapdesignguild.org
>
>   Sitz der Gesellschaft/Registered Office: Walldorf,
>   Germany
>   Vorstand/SAP Executive Board: Henning Kagermann
>   (Sprecher/CEO), Léo Apotheker (stellvertretender
>   Sprecher/Deputy CEO), Werner Brandt, Claus Heinrich,
>   Gerhard Oswald, John Schwarz, Peter Zencke
>   Vorsitzender des Aufsichtsrats/Chairperson of the
>   SAP Supervisory Board: Hasso Plattner
>   Registergericht/Commercial Register Mannheim No
>   HRB 350269
>
>   Diese E-Mail kann Betriebs- oder
>   Geschäftsgeheimnisse oder sonstige vertrauliche
>   Informationen enthalten. Sollten Sie diese E-Mail
>   irrtümlich erhalten haben, ist Ihnen eine
>   Kenntnisnahme des Inhalts, eine Vervielfältigung
>   oder Weitergabe der E-Mail ausdrücklich untersagt.
>   Bitte benachrichtigen Sie uns und vernichten Sie die
>   empfangene E-Mail. Vielen Dank.
>
>   This e-mail may contain trade secrets or privileged,
>   undisclosed, or otherwise confidential information.
>   If you have received this e-mail in error, you are
>   hereby notified that any review, copying, or
>   distribution of it is strictly prohibited. Please
>   inform us immediately and destroy the original
>   transmittal. Thank you for your cooperation.
Jon Gunderson, Ph.D.
Coordinator Information Technology Accessibility
Disability Resources and Educational Services

Rehabilitation Education Center
Room 86
1207 S. Oak Street
Champaign, Illinois 61821

Voice: (217) 244-5870

WWW: http://www.cita.uiuc.edu/
WWW: https://netfiles.uiuc.edu/jongund/www/

Received on Thursday, 17 July 2008 16:45:25 UTC