[chromium-dev] Re: Chrome Keyboard Access, opinions?
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.comwrote: 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 -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
+ CC Scott and Evan, to maintain a good story cross-platform. Any suggestions for a keyboard model here? I'd really like to stay away from the long, complex keyboard combos, also because noone will ever discover that they are there... - Jonas On Mon, Sep 28, 2009 at 10:51 PM, Mohamed Mansour m...@chromium.org wrote: I agree with James, ALT keys should be only used for accessibility, if we want to be able to allow keyboard shortcuts to other toolbars, we need to reorganize our current ones. It would be nice to have the following combinations: CTRL+SHIFT+T --- Main Toolbar CTRL+SHIFT+B --- Main Bookmarks bar CTRL+SHIFT+E --- Extension bar I wish we could use shorter `shortcuts`. I am working with Mr Klink trying to improve the keyboard shortcuts and accessibility within Chrome, and currently Chrome is disabling keyboard users accessing other tool bars, which is a problem. Any suggestions is highly appreciated. -Mohamed On Sat, Sep 26, 2009 at 9:00 PM, James Su su...@chromium.org wrote: 2009/9/26 Jacob Mandelson ja...@mandelson.org On Sat, Sep 26, 2009 at 11:40:07AM -0400, Mohamed Mansour wrote: Hi all, (need UI team feedback and other keyboard guru's) We need a more coherent story for accessing various toolbars. The current toolbars that exist right now are: - Toolbar - Bookmark bar - Extension bar - More in the future Currently ALT + SHIFT + T brings your focus to the toolbar, but there is no way to get to the others. This blocks keyboard users accessing the other bars which is kind of annoying if your a keyboard user. According to Jonas Klink (Accessibility guru) he said that shortcut was only a temporary solution and would like to get rid of it and replace it with something more generic. So we need to think of a uniform access solution to all these toolbars. [...] Maybe we could treat them akin to menus, and have Alt-SomeLetter go move the active focus to the bar? Alt-T and Alt-B seem unbound, but Alt-E (and not Alt-D) opens the Document menu. Alt-F opens the Wrench menu. Can we use some other key bindings rather than Alt- something? Alt is used for activating accesskeys and already caused conflicts between some accelerators. See http://crbug.com/21624. -- Jacob --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Chrome Keyboard Access, opinions?
From an accessibility point-of-view, I'd prefer having the first widget in each toolbar focused when the toolbar itself gains focus (including hottracked and displaying any tooltip that is displayed on mouseover of this widget). On Tue, Sep 29, 2009 at 5:28 PM, Mohamed Mansour m...@chromium.org wrote: What would differentiate which toolbar is currently focused? Would it be ideal to assume the first widget in that toolbar would be focused (hotkeyed), or we would draw some sort of ring around the whole toolbar? -Mohamed On Tue, Sep 29, 2009 at 8:03 PM, Jonas Klink (Google) kl...@chromium.orgwrote: So, to clarify, we would then use ALT+SHIFT+T (currently focusing the toolbar), to cycle keyboard focus through any open toolbars (toolbar-bookmark bar-infobar (restore tabs etc, if visible)-Extensions toolstrips). Does that makes sense to everyone? The shortcut is not ideal, but it might be the best we've got... On Tue, Sep 29, 2009 at 4:26 PM, Scott Violet s...@chromium.org wrote: I would just use the existing accelerator we have to focus the toolbar. -Scott On Tue, Sep 29, 2009 at 3:58 PM, Mohamed Mansour m...@chromium.org wrote: What kind of accelerators do would you like to have? Maybe have a accelerator that traverses only toolbars, and once we are in that toolbar, we can tab through the widgets. -Mohamed On Tue, Sep 29, 2009 at 1:30 PM, Peter Kasting pkast...@google.com wrote: On Tue, Sep 29, 2009 at 10:25 AM, Scott Violet s...@chromium.org wrote: On Tue, Sep 29, 2009 at 10:16 AM, Peter Kasting pkast...@google.com wrote: It seems like when these bars are open, their contents should be in the tab order. You should be able to tab through the contents of a page, into the chrome, and eventually back into the page. I don't think most folks want tab from the omnibox to take you through the menus, then bookmark buttons. I know that would drive me batty. I could see some users wanting it, but I don't think it should be the default. I admit that I totally failed to think through tab in the omnibox -- I was thinking about all the other cases. That said, we've had TONS of requests to make tab from the omnibox work differently (i.e. like how other browsers do it): * When the popup is open, tab rotates through its items * Otherwise, tab moves to the next focusable element I kind of regret that we picked tab for tab to search because it prevents both of these, and I'm not sure we can change it now. It does seem like a bug somehow that you can tab into the omnibox but not out, but I don't know how to fix :( Perhaps we also need the ability to assign accelerators to individual bookmarks/extensions. This has been requested a few times, and brakowski suggested it long ago as a replacement for the home button -- if you can drag a bookmark onto your main toolbar, and give it an alt-home shortcut, then you have your own home button. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] BookmarkHTMLWriterTest failing
I am trying to push http://codereview.chromium.org/155446 , but running into issues with BookmarkHTMLWriterTest on Win tryserver: http://build.chromium.org/buildbot/try-server/builders/win/builds/11093/steps/unit_tests/logs/stdio Anyone have any experience with this test? I have tried to figure out why my CL is breaking the test, but unsuccessful so far... Thankful for any help, Jonas --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: focusRingColor() listening to system settings changes on Windows?
Not knowing the extent of the capabilities here, but could this also be leveraged to respect High Contrast settings on Windows...? We have several bugs open on this (http://code.google.com/p/chromium/issues/detail?id=583, http://code.google.com/p/chromium/issues/detail?id=92), and demand for support seems pretty high. - Jonas On 3/9/09, Darin Fisher da...@chromium.org wrote: Right... there is a big TBD to get someone to implement proper WM_THEMECHANGED support for Chromium. Any takers? -Darin On Mon, Mar 9, 2009 at 4:27 AM, Dean McNamee de...@chromium.org wrote: I would have to guess that if there was, it would be some window message (WM_THEMECHANGED ?) sent to our top level window, and the plumbing would be annoying for it. On Mon, Mar 9, 2009 at 10:21 AM, Jeremy Moskovich jer...@chromium.org wrote: (mailed to random people who I thought might know the answer). In platform/graphics/chromium/ColorChromium.cpp we currently hardcode the value of focusRingColor on OS X Windows. On OS X Safari listens on a notification to see if the user has changed the system focus color. Is there a similar notification mechanism on Windows we should be using? Best regards, Jeremy -- Jonas Klink Software Engineer - Accessibility Google, Inc. Phone: 650.253.8701 Email: kl...@google.com This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: Bookmark Added! GUI redesign ideas
For keyboard users, the most natural flow is in 1A, I would say. Presenting the keyboard (and potentially screen reader) user with the 'Close' button before the edit options might lead many of those users astray. The discoverability here would be (as always with these types of users) top-to-bottom, left-to-right. - Jonas On 12/9/08, Andrew Scherkus [EMAIL PROTECTED] wrote: I do like how the horizontal versions give you extra typing room and have a bit of the long horizontal look of the tab bar, omnibox bar and bookmark bar. Just my $0.02! Andrew On Tue, Dec 9, 2008 at 6:30 PM, Brett Wilson [EMAIL PROTECTED] wrote: Hi Simon, Thanks for the thoughtful mocks. I like the overall feel of the more horizontal versions better for some reason. However, I also like having the Remove link in the upper right. I think of it somewhat like a close box for the bookmark, and I expect its placement to be in the same place. I also kind of expect the close box to be in the lower right, since that's usually where the OK button is in a dialog box. Brett --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
[chromium-dev] Re: Accessibility design doc
Thanks Ben. I added some more descriptive steps and resources on the generation and lifetime of a MSAA request. More comments inline. - Jonas On Tue, Dec 2, 2008 at 7:33 PM, Ben Goodger (Google) [EMAIL PROTECTED]wrote: Thanks for putting this together, Jonas. It's a good start. One area where I think you could expand on the views integration side is to show richer detail for how the views integration works (maybe a diagram with the relevant components, interfaces, etc). Perhaps give a compact example of the lifetime of a MSAA request from the OS and how we respond to it referring to the diagram to show the components involved in formulating the response. Some specific feedback about the way things are right now: - I don't think the a11y code should use view ids to locate various components. I actually don't find view IDs that useful and think they should probably disappear, since they just clutter up the View interface. Agreed. The generated MSAA focus events need to come with a child id, to uniquely identify the view that is receiving focus. As part of the original design, I chose to piggyback on the already existing ViewID enums, rather than creating an extra, redundant accessibility ID. However, if we feel strongly that the ViewIDs should go away, it would certainly be easy to add another ID system instead. - Related to this, code to obtain accessible wrappers for various Browser constructs like the omnibox shouldn't be in the views/ directory. (I think I filed some bugs on this a few weeks/months back). The generic views stuff can live there, but the Browser specific stuff should move into the browser/ dir, and maybe be part of BrowserView. The outward dependency on browser/ is an impediment to using views without browser. If the binding were to live with BrowserView, the code would have direct access to the LocationBarView for example and not need to use view ids. The trouble with the omnibox and the view/browser dependencies is that it itself has somewhat of a split personality. On one hand, it is a View (LocationBarView), which is expected to be included in the View MSAA hierarchy. On the other hand, it also has it's own window (with its own message handler) and can be hit directly with a WM_GETOBJECT through that. If we are fine with having references from browser into view (but not the other way around), I guess that can be done with some trickery. - I count at least 9 methods on views::View related to accessibility. At least some of these, relating to name/role/action/shortcut/etc are metadata. I'd prefer it if there were a metadata object that the View returned through a single function that the wrapper code queries. Most views would return a default metadata object. Specific views with a11y roles would configure the metadata object to their liking. This allows us to keep the View API compact. Agreed. I have a TODO in the code to put this into a metadata object. -Ben On Tue, Dec 2, 2008 at 1:18 PM, Jonas Klink [EMAIL PROTECTED] wrote: Hi all, I have summarized the current state of the Chrome accessibility work, as well as ongoing efforts and outstanding issues (where anyone interested is more than welcome to help out): http://sites.google.com/a/chromium.org/dev/developers/design-documents/accessibility Any feedback, questions or volunteers are as always welcome! Thanks, -- Jonas Klink Software Engineer - Accessibility Google, Inc. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Chromium-dev group. To post to this group, send email to chromium-dev@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/chromium-dev?hl=en -~--~~~~--~~--~--~---
