RE: Keyboard Behaviors for Elements with Role "Grid"

Widgets that include more than one ARIA role need to manage the overall keyboard focus of the widget.  I think in general though the more complex the widget structure the more complicated the keyboard model the user would need to understand to efficiently navigate the functions and data of the widget.  Simple keyboard models may provide "technical" access by people with disabilities, but often do not lead to UIs that are functionally unusable to people with disabilities.  So it is important there be consistency of keyboard models in widget sets both for user to know what keys to use and developers to know what keyboard model to implement.

Ultamently the best test is actual usability testing with people with various disabilities with different keyboard models to see effect on task completion time and learning the keyboard model.

Jon
     

---- Original message ----
>Date: Thu, 17 Jul 2008 13:02:10 +0200
>From: "Schaus, Martin" <martin.schaus@sap.com>  
>Subject: RE: Keyboard  Behaviors for Elements with   Role "Grid"  
>To: "Cain, Sally" <sally.cain@rnib.org.uk>, "Jon Gunderson" <jongund@illinois.edu>, "Schnabel, Stefan" <stefan.schnabel@sap.com>, "Victor Tsaran" <vtsaran@yahoo-inc.com>, "Evans, Donald" <Donald.Evans@corp.aol.com>, "Richard Schwerdtfeger" <schwer@us.ibm.com>, <wai-xtech@w3.org>, <wai-xtech-request@w3.org>
>Cc: "Grigoriadis, Georgios" <georgios.grigoriadis@sap.com>, "Keim, Oliver" <oliver.keim@sap.com>, "Aaron M Leventhal" <aleventh@us.ibm.com>
>
>The interesting questions are: 
>What should happen if you nest a widget or several widgets in one grid cell?
>How do these element(s) receive and lose the focus?
>-Martin
>
>
>-----Original Message-----
>From: Cain, Sally [mailto:sally.cain@rnib.org.uk] 
>Sent: Donnerstag, 17. Juli 2008 12:43
>To: Jon Gunderson; Schnabel, Stefan; Victor Tsaran; Evans, Donald; Richard Schwerdtfeger; wai-xtech@w3.org; wai-xtech-request@w3.org
>Cc: Schaus, Martin; Grigoriadis, Georgios; Keim, Oliver; Aaron M Leventhal
>Subject: RE: Keyboard Behaviors for Elements with Role "Grid"
>
>Jon said:
>I don't think TAB should be used for any navigation within a widget. 
> 
>>I agree with Jon on this. 
>
>Jon said:
>Maybe there should be a SHIFT+TAB for the use you describe for moving between editable cells in a grid.
>
>>Expected use of Shift+tab would to be to move from the grid backwards to the previous control or widget. So I would prefer shift+tab not to be used to navigate within a grid either.
>
>Thanks
>Sally
>
>---- Original message ----
>>Date: Tue, 15 Jul 2008 08:18:41 +0200
>>From: "Schnabel, Stefan" <stefan.schnabel@sap.com> 
>>Subject: RE: Keyboard  Behaviors for Elements with  Role "Grid" 
>>To: "Jon Gunderson" <jongund@illinois.edu>, "Victor Tsaran" <vtsaran@yahoo-inc.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>
>>
>>
>>Okay, now I know what you mean. Sorry, I missed that important point in the description.
>>
>>I have to explain a little bit more the concept.
>>
>>1) The GRID does "know" in its initial state which cells are editable and which are not.
>>2) Based on this knowledge, the TAB key is "directed" by JS code to the next editable cell
>>3) The cell is NOT automatically in edit mode after focusing with TAB, edit mode must be explicitly switched on as described in "Editable Grid Cell Activation:" below.
>>
>>Hope this will answer your questions.
>>
>>Stefan
>>
>>
>>-----Original Message-----
>>From: Jon Gunderson [mailto:jongund@illinois.edu]
>>Sent: Montag, 14. Juli 2008 20:37
>>To: Schnabel, Stefan; Victor Tsaran; Evans, Donald; Richard Schwerdtfeger; wai-xtech@w3.org; wai-xtech-request@w3.org
>>Cc: Schaus, Martin; Grigoriadis, Georgios; Keim, Oliver; Aaron M Leventhal
>>Subject: RE: Keyboard Behaviors for Elements with Role "Grid"
>>
>>Stefan,
>>
>>How does the TAB key know when to stay in the "row" and when to go to the next widget in the application?
>>
>>Doesn't this make the TAB key much less predictable to the user, if they don't know whether they will be going to the next gridcell or to the next widget?
>>
>>Jon
>>
>>
>>
>>---- Original message ----
>>>Date: Mon, 14 Jul 2008 09:19:29 +0200
>>>From: "Schnabel, Stefan" <stefan.schnabel@sap.com> 
>>>Subject: RE: Keyboard  Behaviors for Elements with  Role "Grid" 
>>>To: "Victor Tsaran" <vtsaran@yahoo-inc.com>, "Jon Gunderson" <jongund@illinois.edu>, "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>
>>>
>>>Please re-read carefully all the description (Navigation within Grid). It's all there.
>>>
>>>TAB is NOT used for navigation within grid in general (that is done by ARROW keys),
>>>instead it CAN be used as an alternative for navigation within a grid row and to exit
>>>from an editable element in a cell.
>>>
>>>- Stefan
>>>
>>>
>>>-----Original Message-----
>>>From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf Of Victor Tsaran
>>>Sent: Freitag, 11. Juli 2008 18:34
>>>To: 'Jon Gunderson'; Schnabel, Stefan; 'Evans, Donald'; 'Richard Schwerdtfeger'; wai-xtech@w3.org; wai-xtech-request@w3.org
>>>Cc: Schaus, Martin; Grigoriadis, Georgios; Keim, Oliver; 'Aaron M Leventhal'
>>>Subject: RE: Keyboard Behaviors for Elements with Role "Grid"
>>>
>>>
>>>+1 for Jon's comments.
>>>This will become particuarly important with multiple web 2.0 widgets on a
>>>single page.
>>>There is, however, a challenge with providing access to read-only cells
>>>because of the number of states and handlers that a developer has to
>>>maintain in order to differentiate between editable cells and read-only
>>>ones. But this is no way an excuse, the problem still needs to be addressed.
>>>
>>>Regards,
>>>Victor
>>>
>>>
>>>-----Original Message-----
>>>From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On Behalf
>>>Of Jon Gunderson
>>>Sent: Friday, July 11, 2008 6:51 AM
>>>To: Schnabel, Stefan; Evans, Donald; Richard Schwerdtfeger;
>>>wai-xtech@w3.org; wai-xtech-request@w3.org
>>>Cc: Schaus, Martin; Grigoriadis, Georgios; Keim, Oliver; Aaron M Leventhal
>>>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 <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/
>>>
>>>
>>>
>>>
>>>
>>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/
>>
>>
>>
>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/
>
>
>
>
>
>
>-- 
>DISCLAIMER:
>
>NOTICE: The information contained in this email and any attachments is 
>confidential and may be privileged.  If you are not the intended 
>recipient you should not use, disclose, distribute or copy any of the 
>content of it or of any attachment; you are requested to notify the 
>sender immediately of your receipt of the email and then to delete it 
>and any attachments from your system.
>
>RNIB endeavours to ensure that emails and any attachments generated by
>its staff are free from viruses or other contaminants.  However, it 
>cannot accept any responsibility for any  such which are transmitted.
>We therefore recommend you scan all attachments.
>
>Please note that the statements and views expressed in this email and 
>any attachments are those of the author and do not necessarily represent
>those of RNIB.
>
>RNIB Registered Charity Number: 226227
>
>Website: http://www.rnib.org.uk
>
>
>
>This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com
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 14:06:15 UTC