RE: Keyboard Behaviors for Elements with Role "Grid"

Yeah.

>>>>
>>>>   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
>>>>

- Stefan



-----Original Message-----
From: Jon Gunderson [mailto:jongund@illinois.edu] 
Sent: Mittwoch, 16. Juli 2008 15:29
To: Keim, Oliver; Schaus, Martin; Schnabel, Stefan; Victor Tsaran; Evans, Donald; Richard Schwerdtfeger; wai-xtech@w3.org; wai-xtech-request@w3.org
Cc: Grigoriadis, Georgios; Aaron M Leventhal
Subject: RE: Keyboard Behaviors for Elements with Role "Grid"

In the keyboard model you describe how does a user exit the grid and move to the next widget/link/form control without going through every editable cell in the grid?

Jon


---- Original message ----
>Date: Wed, 16 Jul 2008 08:33:19 +0200
>From: "Keim, Oliver" <oliver.keim@sap.com>  
>Subject: RE: Keyboard  Behaviors for Elements with  Role "Grid"  
>To: "Schaus, Martin" <martin.schaus@sap.com>, "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>, "Aaron M Leventhal" <aleventh@us.ibm.com>
>
>
>Hi,
>
>for skipping the "complex control" (a control which exists of a set of controls) we (SAP) favor to use a group skipping mechanism, which was in OS2/SAP Ctrl+Tab/Shift+Ctrl+Tab or in MS Office apps F6/Shift+F6.	Ctrl+Tab is also used within MDI apps, which is a similar behavior, skipping documents (which often are a set of combined elements).
>
>One of the reasons to have a group/view skipping mechanism.
>
>Important also is, that the complex control remembers and restores the last context (selection, focus position) when tabbing in again.
>
>Tab is the keystroke which is very often used to tab between widgets in composite controls. See excel grid, see MS Access tables, see forms, see Firefox bookmarks, see chart controls, see other graphics controls (like powerpoint/visio/OO Draw content). It is in use within SAP applications and it's widgets for almost 20 years (SAP Gui table control was the first within SAP applications).
>
>regards, Oliver.
> 
>
>-----Original Message-----
>From: Schaus, Martin 
>Sent: Dienstag, 15. Juli 2008 18:21
>To: Jon Gunderson; Schnabel, Stefan; Victor Tsaran; Evans, Donald; Richard Schwerdtfeger; wai-xtech@w3.org; wai-xtech-request@w3.org
>Cc: Grigoriadis, Georgios; Keim, Oliver; Aaron M Leventhal
>Subject: RE: Keyboard Behaviors for Elements with Role "Grid"
>
>In Stefan proposal is a Editable Grid Cell Activation. 
>This allows to switch between a navigation mode with the arrow keys and an edit mode where you can tab to every editable cell.
>
>If you only allow arrow navigation you will have some issues.
>In that case for example: 
>How does one leave an input field inside a grid cell and go to the next editable cell? 
>With tab, I hope, because arrow keys (left, right) are important in input fields to navigate the text. 
>Same counts for select box with up and down arrow keys. 
>In the described example of Jon the tab key stoke will lead to the next element after the Grid, which is not what the user wants because she likes 
>to edit the next editable cell.
>
>
>- Martin
>
>
>-----Original Message-----
>From: Jon Gunderson [mailto:jongund@illinois.edu] 
>Sent: Dienstag, 15. Juli 2008 17:48
>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"
>
>But in a grid like a grade book almost every cell is editable, so the tab would be the same as the left arrow key, plus it would again result in lots of TABs to get by the widget.  
>
>How does a developer know when there are two many things to use tab to go to editable cells?
>
>What does the user need to do to get to the next widget?  In the model you propose they have to tab through every editable cell in a grid before they get to the next widget?
>
>I don't think TAB should be used for any navigation within a widget.  
>
>Maybe there should be a SHIFT+TAB for the use you describe for moving between editable cells in a grid.
>
>Jon
>
>
>---- 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
>>>>
>>>>   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/
>
>
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 Wednesday, 16 July 2008 14:18:17 UTC