So, the background story here is as follows: in Windows, the typical toolbar
will have one tabstop (accessible through tab or shift-tab) on the whole
toolbar, and buttons will then be traversable using left and right arrow
keys. For instance, this behavior can be seen in the Quick Launch toolbar,
by setting keyboard focus to the Start button, hitting tab, and then arrow
through your application shortcuts. Upon gaining keyboard focus, the first
button gets hottracked.
Our initial solution for the toolbar tried to duplicate this behavior as
closely as possible, with a few exceptions. Firstly, my suggestion to add
the toolbar to the taborder (accessible by tab or shift-tab, as expected)
was vetoed since we did not want to introduce any other tabstop in the UI
other than the omnibox and the web content itself. Hence the introduction of
a fairly clunky keyboard shortcut to focus the toolbar (ALT+SHIFT+T) came
about. If our position on the tabstops have changed, adding a tabstop to the
toolbars (and then traverse each button using the arrow keys, once a given
toolbar has focus) would best match Windows behavior.

Secondly, to further emphasize focus highlighting (beyond hottracking) I
also made sure that any existing tooltip would be triggered upon button
traversal.

Thirdly, we have keyboard shortcuts to access various functionality in the
toolbar (F5 for refresh, ALT-keys for the menus, etc).

Trying to extend our keyboard access to multiple toolbars (bookmarks,
infobars, extensions), I propose the following:

   1. Once a toolbar has focus, navigate buttons using the arrow keys, with
   hottracking and tooltips highlighting which button has focus (consistent
   with Windows and the behavior we have today in the toolbar). Also keep the
   current keyboard shortcuts, where a standardized option for such a shortcut
   exists.
   2. The harder problem is to figure out how to focus the first toolbar,
   and then how to move focus between the toolbars visible. We could take any
   of a couple of approaches:
      1. Add tabstops on the toolbars.
      2. Add a mode which when activated will add tabstops to the toolbars.
      This mode could be entered by a keyboard shortcut, such as
ALT+SHIFT+T, and
      perhaps exited by Esc (or using the mouse to focus anything else in the
      page). If we support Esc, that should bring focus back to
previously focused
      item, or at least a known, consistent place in the UI.

I think that 2.1 is not really feasible, and probably not desirable. I'd
place my vote for 2.2, as outlined above (in combination with the maintained
characteristics outlined in #1).

Hope that makes things a bit clearer, thanks,
Jonas

On Fri, Oct 9, 2009 at 11:31 AM, Dominic Mazzoni <dmazz...@google.com>wrote:

> On Fri, Oct 9, 2009 at 11:15 AM, Jay Campan <jcam...@chromium.org> wrote:
>
>> > +1.  To a beginner, left and right arrow might be more intuitive and an
>> > opportunity for us to innovate.  But millions of people use
>> screenreaders,
>> > have trouble using the mouse, or are just power users who love keyboard
>> > shortcuts, and we're just frustrating them by not letting them use
>> standard
>> > control navigation keys (like Tab and Shift+Tab) that work throughout
>> > Windows.
>> I'll let Jonas comment as I am not sure I remember how we came up with
>> that design.
>
>
> Definitely.  BTW, I just joined the accessibility team and I'm hoping to
> help continue much of the great work Jonas has done so far.  He's thought
> about this a lot more than I have so far, though!
>
>
>> > 2. In addition, when any control in the toolbar gains focus via the
>> keyboard
>> > (or maybe always), the whole toolbar highlights in some subtle way
>> > indicating the whole toolbar is the containing region to the focused
>> > control.  This enables the user to press left and right arrow keys as an
>> > additional way to move the focus to other controls in the toolbar - this
>> is
>> > similar to how when you have a radio button active, you can use arrows
>> to
>> > change the selected radio button.  However, if at any point they press
>> Tab
>> > or Shift+Tab, they'll navigate among all controls, on or off the
>> toolbar,
>> > exactly as one would expect.
>> I see your point with the radio-buttons, but I am not entirely
>> convinced it would be good for the toolbar.
>> With radio buttons, using the arrows is the only way to focus another
>> button (when tab traversing only the selected radio-buttons of a group
>> gets focused).
>>
>
> Agreed. Personally I would prefer just supporting Tab and Shift+Tab, plus
> some extra shortcuts to jump to one or more controls - but I think there's a
> lot of room for innovation and compromise as long as Tab navigation isn't
> broken.
>
> - Dominic
>
>

--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com 
View archives, change email options, or unsubscribe: 
    http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---

Reply via email to