Re: [Fwd: [Bug 53580] Changed - KEYNAV: GtkTreeView]

[Peter Korn <peter korn sun com>]

Hi Calumn,

> > [...general discussion on table column header focus...]
> 
> Option 1) Tabbing into the list gives focus to the first column header
> in the list, rather than the list of items itself.  At this point, the
> left/right arrow keys move focus between the headers, and pressing Tab
> for a second time moves focus into the main body of the list.  When the
> list items have focus, Shift+Tab moves focus back to the column headers,
> and Tab moves focus forward out of the list control altogether.
> 
> Advantages: Totally consistent with our proposed navigation mechanism
> for notebook/tab controls, and makes it obvious that focus can even be
> given to the headers at all, by explicitly including them in the tab
> sequence.
> 
> Disadvantages: Requires one extra press of the Tab key for the most
> common action (giving focus to the list items themselves).  Also, the
> "first" column header in a list is often the header for a column of
> icons, which is generally very small in comparison to the other headers,
> so the fact that it had gained focus may not be immediately obvious-- it
> may look as though the focus had just disappeared.

Anything that can get keyboard focus *must* show visually that it has keyboard
focus.  To quote the controlling section of Section 508 regulations:

 § 1194.21(c):
   A well-defined on-screen indication of the current focus shall be provided
   that moves among interactive interface elements as the input focus changes.
   The focus shall be programmatically exposed so that assistive technology
   can track focus and focus changes.

So, whether we go with option 1 or option 2, it's important that when the focus
is on the header, there be some visual indication of same.

> Option 2) Tabbing into the list initially gives focus to the list items,
> as it does now.  Pressing Tab or Shift+Tab again moves focus right back
> out of the list control again, as it does now.  Focus is given to the
> column headers by tabbing into the list, then pressing Ctrl+PgUp.  Once
> the headers have focus, left/right arrow keys move focus between the
> headers as in suggestion 1, pressing Tab gives focus back to the list
> items, and pressing Shift+Tab backs focus out of the list control
> altogether.
> 
> Advantages: No extra steps added to the tab sequence.  Still has some
> consistency with our proposal for notebook/tab controls, where we
> suggest that Ctrl+PgUp should move focus from a control on a tabbed page
> to the tab control itself.
> 
> Disadvantages: Functionality is well-hidden, you wouldn't find it
> without some experimentation or (more likely) somebody telling you about
> it.
> 
> Any thoughts/preferences/better ideas?  Just writing this email has made
> me lean more towards option 1, but comments would be appreciated.


I rather like option #2, but I have a concern that it may be difficult for some
users to know that they are in a table such that Ctrl+PgUp is available to
them.  For example, will a blind, screen reader users, be able to rapidly
understand that they are in a table cell just from tabbing into it?  This is,
perhaps, really a question for the user-interface of the screen reader.  But
that's the crux of my concern with option #2.


Peter