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

Re: Navigation/performaing an action within a grid

From: Earl Johnson <earlj.biker@gmail.com>
Date: Wed, 27 Aug 2008 15:31:46 -0700
Message-ID: <f9806ac80808271531m67b23736rae76bb0b499fb22b@mail.gmail.com>
To: "Hadi Rangin" <hadi@uiuc.edu>
Cc: "W3C WAI-Xtech" <wai-xtech@w3.org>, "Donald Amos" <dwamos@pstcc.edu>, "Jon Gunderson" <jongund@uiuc.edu>
Hi Hadi;

Responses inline, see the EJs.

Earl

On Tue, Aug 26, 2008 at 7:53 AM, Hadi Rangin <hadi@uiuc.edu> wrote:

> Hi Earl,
>
> Thank you very much for your feedback/comments.
> As indicated, the proposed behavior is not complete and I am hoping we all
> together can complete and tune it up. Please find my response/suggestion
> below:
>
>  1. What happens if the grid cell is in Action mode, it contains actionable
>> elements, and it also has a grid embedded in it that contains actionable
>> elements itself?
>>
>
> I suggest to pass the current mode recursively throughout the nested grids.
> It means if the most outer grid is in action mode, all nested grids will
> inherit the current mode. Does




































> anyone see any problem with this?
>

EJ  I think the final agreement was the navigation mode was preferred.

>
>
>  2. As a visual keyboard user, I like the thought of having a mode that
>> [I'm
>> assuming] instantly shows all actionable elements in the grid cell, text
>> fields in particular; but should Navigation be the default mode instead?
>>  = The DHTML tables I've run across expose links, check boxes, buttons,
>> etc but don't expose text fields and areas till they are clicked.
>>  = This is the default mode spreadsheets use in my experience.
>>  = Does the "show widget role" guidance require specific styling guidance?
>>       * Is this part of what you had in mind?
>>
>
> Setting the Action mode as default mode will help users to quickly
> interacting with the form controls in the grid cells without taking any
> extra steps. Keyboard users in particular screen reader users are already
> used to complex key combinations and using their fingers and toes when
> interacting with form controls. :) So pressing a couple of extra keys won't
> change their lives very much.
> You can interact with all actionable items including form controls and in
> particular text boxes immediately without going through any extra step. So
> if in Action mode you focus to a text box, you should be able to manipulate
> it immediately.
> As far as if it is like Excel, I don't think so. If I am not mistaking, in
> Excel, you have to press F2 in order to to be able to edit the current
> value. The behavior In the keyboard model I am suggesting, when you are in
> Action mode, you can manipulate the value of a text box as soon as you focus
> to it.
>

EJ   N/A given navigation mode will be default.

>
>
>  3. Action mode being the default works for the first grid cell but what
>> happens focus is on the last actionable element in a cell and tab is
>> pressed?
>>  = Being default, this suggests to me that pressing tab should keep input
>> mode in Action mode and move focus to the next cell with an actionable
>> element in it.
>>  = Isn't this closer to how spreadsheets work?
>>
>
> I am not sure that I understand your questions. Of course, we can always
> discuss it further in our teleconference but so far I understand, you are
> concerned about pressing tab key off of last actionable element in a grid.
> The tab key should take the focus to the next focusable element in the page
> and the current mode remains unchanged (Action mode).
>

EJ   The consensus here was the user stays in Action mode until F2 was
toggled.

       btw - I think this is not how spreadsheets work.

>
>
>  4. The proposal suggests a Tab press moves focus out of the grid entirely
>> when in Action mode and focus is on the last actionable element.Perhaps a
>> Tab press should act more like an F2 press first then have it move focus
>> out
>> of the grid?
>>  = I'm assuming F2 keeps focus on the current cell.
>>  = Another assumption is, while still different, this action will be
>> closer to what the novice , standard data table user expects as opposed to
>> what is now proposed - focus leaves the table.
>>
>
> I do not see any need to press F2 in order to leave the grid. The action
> mode will provide an environment similar to what users are experiencing
> today. The Navigation mode is thought mainly for Screen Reader users to
> navigate through the grid to understand what kind of data they are dealing
> with without manipulating it accidentally. So if you as a visual keyboard
> user want to interact with your grid and all elements in it, you can decide
> how quickly you can get to your desired elements. If your desired actionable
> elements are a few tab key away, then you press the tab key to get there;
> note that you are by default in Action mode. If you are like me a non-visual
> keyboard user, then you switch to Navigation mode to familiarize yourself
> with the layout and elements in your grid first. While I am navigation
> through the grid, if I run into an actionable element that I want to
> manipulate, then I switch to the Action mode, perform desired manipulation,
> switch back to Navigation mode and continue with my interaction.
>
EJ   I was suggesting that when focus is on the last actionable item in the
grid that the following occur:
   a. Mode changes from Action to Navigation
   b. The next Tab press moves focus out of he data grid into the next
focusable element outside the grid.

   My unproven hypothesis is the user will be less surprised by this
occuring than what happens if focus were to leave the grid entirely. This
would seem especially true if the last  cell with editable content was in
the top 1/3, or less, of a grid.
this is easier to the


>
>  6. The arrow keys work inside groups of radio [and check?] buttons?
>>
> Yes as long as you are in Action mode.
>
>  7. Should Arrow keys move focus as described if in Action mode and input
>> focus is on the last actionable element?
>>
>
> Do you mean if the arrow keys would move the focus to the next actionable
> element when you are in a text box?
> If you mean it, then no. If you are in the Action mode and the focus is on
> a text box, the arrow keys, home, end keys, backspace and delete keys,
> control+backspace and control+delete keys perform their usual edit
> functions.
>
EJ   Yes and never mind the suggestion.

>
>  8. Does Cntrl+Tab move focus out of  a Text area?
>>
>
> No.  You can use tab and shift+tab to move out and in to a text area.
> Isn't control+tab is reserved by browsers to switch to the next browser
> tab?
>

EJ   Doh! To bad tho, cntrl+tab is how desktop toolkits do it in my
experience.

>
>
>  9. The user of standard tables will be confused when they run across DHTML
>> tables.
>>   = Can this styleguide provide visual style guidance that helps user
>> recognition on sites containing standard and DHTML tables without leaving
>> the developer confused]?.
>>
> I don't see the confusion you see.
>
>
> Thanks,
> Hadi
>
>
Received on Wednesday, 27 August 2008 22:32:22 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:37 UTC