User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Firefox/31.0 Build ID: 20141011074935 Steps to reproduce: Location: From the browser menu, select View>Toolbars>Customize. http://www.dhs.gov/sites/default/files/publications/DHS%20Section%20508%20Compliance%20Test%20Process%20for%20Applications%203.3.pdf#page=23 Actual results: The icons on the Customize Firefox page are drag and drop and not accessible via the keyboard. The entire page is not accessible via the keyboard unless the mouse is used to place the cursor in the page. Expected results: Keyboard access to all elements.

You need a keyword for accessibility; that doesn't fit within your other UX categories.

Comment on attachment 8542679 [details] FF_31_01.jpg Fails Section 508 1194.21 (Software Applications and Operating Systems) a (Executing Function From Keyboard), c (Input Focus), 1194.31 (Functional performance) a (Blindness), b (Low vision) Baselines: B01, B02, B03, B04

MS office works around this by providing a clumsy dialog that lets you move items around. I should like to think that we could do better, but I've not investigated in more detail yet.

I was planning to make this a meta bug but I don't really see how to usefully split it up. What would make sense to do here, as best I can tell, is: a) to make the toolbarpaletteitems keyboard-focusable (tabindex=0) b) to let you use the arrow keys to navigate between them, including between different customizable areas like toolbars and panels (when using accel-arrow keys) c) to implement a 'selected state' activated and deactivated using space and/or enter/return d) to move items along when arrowing iff they are selected e) (could be a separate bug, but needs all the above to happen first anyway) add some kind of tip/help that can help the user use this interface David & Philipp, does this make sense to you?

(In reply to :Gijs Kruitbosch from comment #4) > d) to move items along when arrowing iff they are selected I'm not sure how this will work for moving between areas. Maybe we could show a tooltip over each area that says something like "Press (M) to move this item to the menu" or "Press (T) to move this item to the toolbar".

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #5) > (In reply to :Gijs Kruitbosch from comment #4) > > d) to move items along when arrowing iff they are selected > > I'm not sure how this will work for moving between areas. Maybe we could > show a tooltip over each area that says something like "Press (M) to move > this item to the menu" or "Press (T) to move this item to the toolbar". Yeah, I figured this would be covered by (In reply to :Gijs Kruitbosch from comment #4) > b) to let you use the arrow keys to navigate between them, including between > different customizable areas like toolbars and panels (when using > accel-arrow keys) so using accel-arrow. But I like the "accesskey" idea, too; it'll probably be faster that way.

Sounds exciting :)

Correct me if I'm wrong, but I thought our entire toolbar and main menu were not keyboard accessible at the moment. That means even when a user could customize their toolbar using the keyboard, he would still only be able to use that customized UI with the mouse.

Some items are customizable and keyboard accessible, such as the location bar (Ctrl+L for Windows/Linux, Cmd+L on OSX), search bar (Ctrl/Cmd+K), and the Bookmarks button (Ctrl/Cmd+D).

Right... Digging into this a little deeper, all the items already have context menus that allow for adding to the toolbar and the menu. Could we solve the issue by just making these menus accessible with the keyboard?

Review commit: https://reviewboard.mozilla.org/r/48231/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/48231/

Comment on attachment 8744000 [details] MozReview Request: Bug 1116578 - Make customize mode keyboard accessible by allowing tabbing through the toolbarpaletteitems and using the context menu key (Shift+F10) on Windows to open the context menu and move items between customizable areas. r?gijs https://reviewboard.mozilla.org/r/48231/#review44931 I have some questions/suggestions before r+... mainly: how do people open the context menu on OS X? Searching the web, there seems to be no shortcut for it. We could create our own, but it wouldn't be very discoverable... So maybe this needs to be Windows/Linux-only? I dunno. Maybe Marco can help? ::: browser/base/content/browser.css:343 (Diff revision 1) > } > > +toolbarpaletteitem[place="palette"], > +toolbarpaletteitem[place="panel"], > +toolbarpaletteitem[place="toolbar"] { > + -moz-user-focus: normal; Do we need both this and the tabindex? ::: browser/themes/shared/customizableui/customizeMode.inc.css:264 (Diff revision 1) > +toolbarpaletteitem[place="palette"]:focus, > +toolbarpaletteitem[place="panel"]:focus, > +toolbarpaletteitem[place="toolbar"]:focus { Can we use -moz-focusring so these don't show up for mouse clicks / drags? ::: browser/themes/shared/customizableui/customizeMode.inc.css:267 (Diff revision 1) > + outline: 1px dotted rgba(0,0,0,.5); > + outline-offset: -5px; > + -moz-outline-radius: 2.5px; This looks like it'll look pretty good on Windows and Linux, but it'll look a bit out of place on OS X. Is there any chance we could implement the blue-y focus styling that we use elsewhere? I think there's probably CSS in toolkit's in-content common stylesheet that you can steal for this purpose.

Marco, is there some sensible way of opening a context menu on OS X with the keyboard outside of voiceover (or even inside of voiceover, for that matter...) ?

Comment on attachment 8744000 [details] MozReview Request: Bug 1116578 - Make customize mode keyboard accessible by allowing tabbing through the toolbarpaletteitems and using the context menu key (Shift+F10) on Windows to open the context menu and move items between customizable areas. r?gijs Review request updated; see interdiff: https://reviewboard.mozilla.org/r/48231/diff/1-2/

(In reply to :Gijs Kruitbosch from comment #13) > Marco, is there some sensible way of opening a context menu on OS X with the > keyboard outside of voiceover (or even inside of voiceover, for that > matter...) ? With VoiceOver on, the key combination is Control+Option+Shift+M. Without VoiceOver, the situation is rather dismal, as can be read, among others, here: http://apple.stackexchange.com/questions/32715/how-do-i-open-the-context-menu-from-a-mac-keyboard BTW: Shift+F10 isn't Windows-only, works the same on Linux/GNOME, too.

Comment on attachment 8744000 [details] MozReview Request: Bug 1116578 - Make customize mode keyboard accessible by allowing tabbing through the toolbarpaletteitems and using the context menu key (Shift+F10) on Windows to open the context menu and move items between customizable areas. r?gijs https://reviewboard.mozilla.org/r/48231/#review45141 r=me with the disabled items addressed (whether in code or by saying "nope, I think the current behaviour is right"), and the commit message including linux somehow. It seems like disabled items shouldn't be focusable (e.g. not the url bar container, or the all tabs button, because you can't move them). Or is it platform convention to make them focusable? In menus, I guess they do sit in the arrow list... somewhat surprising, but I guess at least now you can open the context menu and see that something isn't movable, whereas otherwise you'll just wonder why it's being skipped by focus... Note that I found it somewhat surprising that if you: 1. use the keyboard to move an item 2. leave customize mode 3. re-enter customize mode you then get focus rings even when using the mouse. But I don't think that's too big a deal, and it isn't easily fixable given our focus detection style stuff. Seems too much of an edge-case to block shipping this on, though.

(In reply to :Gijs Kruitbosch from comment #16) > Comment on attachment 8744000 [details] > MozReview Request: Bug 1116578 - Make customize mode keyboard accessible by > allowing tabbing through the toolbarpaletteitems and using the context menu > key (Shift+F10) on Windows to open the context menu and move items between > customizable areas. r?gijs > > https://reviewboard.mozilla.org/r/48231/#review45141 > > r=me with the disabled items addressed (whether in code or by saying "nope, > I think the current behaviour is right"), and the commit message including > linux somehow. > > It seems like disabled items shouldn't be focusable (e.g. not the url bar > container, or the all tabs button, because you can't move them). Or is it > platform convention to make them focusable? In menus, I guess they do sit in > the arrow list... somewhat surprising, but I guess at least now you can open > the context menu and see that something isn't movable, whereas otherwise > you'll just wonder why it's being skipped by focus... I would prefer to leave them focusable since it mirrors how menus work as well as allows users to see that they are not movable (though that could be debated also by having it just skipped too). > Note that I found it somewhat surprising that if you: > 1. use the keyboard to move an item > 2. leave customize mode > 3. re-enter customize mode > > you then get focus rings even when using the mouse. But I don't think that's > too big a deal, and it isn't easily fixable given our focus detection style > stuff. Seems too much of an edge-case to block shipping this on, though. This is by design. See bug 601122 and bug 418521 comment 34. Once Tab (and Alt on Windows) are pressed, focusrings will show up until the application is restarted.

Release Note Request (optional, but appreciated) [Why is this notable]: Adds accessibility support for customizing Firefox [Suggested wording]: Use Tab and Shift+F10 to Customize Firefox using a keyboard [Links (documentation, blog post, etc)]: tbd

Added to Fx48 Aurora release notes

I tested using Firefox 48beta1 across platforms (Windows 10, Windows 8.1 and Ubuntu 16.04 64-bit). I confirm that this is verified fixed (user is now able to play with the tools from customization using the keyboard) but there were two new issues found that will be worked separately.