1. Open Bookmarks/Organize Bookmarks. 2. Using the keyboard, try to get to the buttons at the top "Organize", "Views", and "Import and Export". It is not possible.
Additional info: Neither tabbing around the dialog, nor using any of the possible letters in the word "Organize", for example, will allow keyboard access to these dropdowns.
This UI should not have made it past the review stage. Keyboard support is a bare minimum a11y requirement for any new UI that gets checked in.
(In reply to comment #2) > This UI should not have made it past the review stage. Keyboard support is a > bare minimum a11y requirement for any new UI that gets checked in. I disagree, fwiw. It's fine to be checked in, but when it was, the author (or reviewer) should have filed this follow-up bug and marked it blocking?. We support sec508 and a11y in releases, but not in nightlies.
Flags: blocking-firefox3? → blocking-firefox3+
Well, checking for basic a11y used to be part of the review requirements -- which pointed to the XUL a11y guidelines on MDC. I don't know what happened to that review requirements doc that had that.
Aaron, following our discussion on IRC the other day, I modified the XUL file to add a class="tabbable" attribute to these buttons. The result is that I can now tab to them, but cannot activate them using the keyboard. ENTER, SPACE, DOWN ARROW all fail to activate the dropdown menu behind it. Only a mouse click, executed either by the mouse or the JAWS cursor, will drop down the menus. So while there is a solution to allow them to be focused, the problem of actually activating them remains.
Are they using click handlers on those elements? What kind of XUL elements are they?
Priority: -- → P2
Target Milestone: --- → Firefox 3 M10
(In reply to comment #7) > What kind of XUL elements are they? Toolbarbuttons. As mentioned in bug 397111, we should probably be using a standard menu bar.
(In reply to comment #6) > Aaron, following our discussion on IRC the other day, I modified the XUL file > to add a class="tabbable" attribute to these buttons. The result is that I can > now tab to them, but cannot activate them using the keyboard. ENTER, SPACE, > DOWN ARROW all fail to activate the dropdown menu behind it. Only a mouse > click, executed either by the mouse or the JAWS cursor, will drop down the > menus. So while there is a solution to allow them to be focused, the problem > of actually activating them remains. > Couldn't you fix that by adding onkeypress handlers to them? (In reply to comment #9) > (In reply to comment #7) > > What kind of XUL elements are they? > > Toolbarbuttons. > > As mentioned in bug 397111, we should probably be using a standard menu bar. > So that bug is fixed, does that mean this one is, too?
(In reply to comment #10) > (In reply to comment #9) > > (In reply to comment #7) > > > What kind of XUL elements are they? > > > > Toolbarbuttons. > > > > As mentioned in bug 397111, we should probably be using a standard menu bar. > > > So that bug is fixed, does that mean this one is, too? No, this is still an issue.
Seems like we need to work to try to get an owner for this. Dao, would you be willing to take it?
Well, is making the buttons reachable with tab but not with accesskeys enough?
I'll let Marco decide, but personally I find the tab order annoying already. It's hard to see where focus is in some cases, and it's a cluttered tab order. I also noticed additional problems: 1) when a search is performed new inaccessible buttons appear (not in the tab order): All bookmarks, bookmarks menu, bookmarks toolbar, history 2) After typing in search, the next tab press selects the text instead of move forward. After that, you still cannot tab out of the box now matter how many times you press tab 3) Quick search is usually control+K (minor, but would be more consistent)
I already tried putting them in the tab ordcer, and they were focusable, but could not be activated. Personally, I'd prefer for these things to be plain ordinary menu items. Style them visually as you like, but make them menu bar items. That way, it's easy to get to them with the keyboard, and they drop down menus anyway. :-)
Created attachment 299774 [details] [diff] [review] patch v1.1 forgot to remove PlacesToolbar from places.xul
Hrm, did you test this on Mac?
No, sorry, I can't. I actually don't know what the expected look and behavior on Mac is.
Well, basically, it should remain a toolbar, as this window already has a menubar on Mac. As far as i remember, mac code takes the first menubar element out of a window, hides it and use it contents for the native menubar. So, there are two ways you could address this: 1. Make sure the current browser-menubar is listed first (likely by changing the point in which we include browserMountPoint.inc), then style the other menubar so it looks like a toolbar. 2. #ifdef hell.
I just built with this patch, and just wanted to give you guys a heads-up that this is going in the right direction! In fact, the Mac problems not withstanding, this is going to be very accessible once the patch lands. One thought on the Mac issue: Since the Show All Bookmarks opens a completely new window, I would think that the menu bar Mac should use is this one rather than the default browser menu bar. Once we get a11y on Mac, we definitely will want this menu bar in that window instead of the default browser menu bar.
Created attachment 300052 [details] [diff] [review] patch v2 excluding OS X this time https://build.mozilla.org/tryserver-builds/2008-01-29_07:email@example.com/
Created attachment 300083 [details] [diff] [review] patch v2.1 -w Per beltzner, we want to keep the toolbarbutton appearance. I also added the dropmarker back, which he says would be minor but wanted too.
Comment on attachment 300083 [details] [diff] [review] patch v2.1 -w that's the version without the whitespace changes
Created attachment 300089 [details] [diff] [review] patch v2.1
This is just awful... any chance you could come up with a hack to make these accesskey work manually (Either by a keypress handler or by xul-key elements)?
Accesskey modifiers are subject to user prefs (hidden in about:config but documented): http://kb.mozillazine.org/Accessibility_features_of_Firefox
Mano asked me to point to bug 204944 (attachment 141881 [details] [diff] [review] in particular). Would be nice to get a fix like that in rather than this workaround.
What I consider a workaround is the Mac code respectively the current code, because functionally we really want a menubar, as this bug and bug 397111 (which didn't fix the left and right arrow keys, btw) show.
(In reply to comment #14) > 1) when a search is performed new inaccessible buttons appear (not in the tab > order): All bookmarks, bookmarks menu, bookmarks toolbar, history Confirmed, and bug 414750 filed. > 2) After typing in search, the next tab press selects the text instead of move > forward. After that, you still cannot tab out of the box now matter how many > times you press tab I could reproduce the part that tabbing once does not appear to take focus to a different control. However I could not reproduce the not getting out of there at all part. For me, a second press of TAB moves to the folder tree. Mentioned the first part in bug 414750 as well. Fixing the tab order once should be enough to also fix that bit. > 3) Quick search is usually control+K (minor, but would be more consistent) Hmm, that depends on whether you view this as a separate aplication (like ChatZilla) or as a normal dialog. In a normal dialog, you hardly ever find a shortcut like Control+<Something>. In an application-like window, you would. I am a bit uncertain about the intended state of this window.
(In reply to comment #28) > This is just awful... any chance you could come up with a hack to make these > accesskey work manually (Either by a keypress handler or by xul-key elements)? The problem with the current implementation of the dialog is that these items such as "Organize" etc. aren't discoverable at all. They are not in the tab order, and there's no menu bar. Simply giving them access keys means that, in order to be able to use the dialog, a blind person will be forced to read the documentation, to know that these access keys are available. On the other hand, if these buttons were in the tab order, and they'd react to SPACE or ENTER, or if they were a menu bar alternatively, they'd be discoverable. It is common for a blind person to check whether a particular window has a menu bar, so this would make things immediately discoverable in an intuitive manner. So if you make it a menu bar, which I'd prefer over putting regular buttons in the tab order, you can still style them differently so they look like toolbar buttons instead.
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
Created attachment 300567 [details] [diff] [review] patch v3 added class="tabbable" for Mac Kevin: Could you please add a :focus styling to pinstripe? Otherwise it's hard to tell where the focus goes when tabbing.
Created attachment 300612 [details] [diff] [review] patch v4 another Mac fix
Comment on attachment 300612 [details] [diff] [review] patch v4 r=mano.
Attachment #300612 - Flags: review?(mano) → review+
Comment on attachment 300612 [details] [diff] [review] patch v4 late-l10n stuff needs explicit approval.
Attachment #300612 - Flags: approval1.9?
The places.xul changes have bitrotted. Mind attaching an updated patch for me, please, just so I can make sure I get everything?
Status: NEW → ASSIGNED
Created attachment 301877 [details] [diff] [review] updated patch
Attachment #300612 - Attachment is obsolete: true
mozilla/browser/components/places/content/places.js 1.126 mozilla/browser/components/places/content/places.xul 1.105 mozilla/browser/locales/en-US/chrome/browser/places/places.dtd 1.41 mozilla/browser/themes/gnomestripe/browser/places/organizer.css 1.9 mozilla/browser/themes/winstripe/browser/places/organizer.css 1.3
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
Depends on: 421529
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9) Gecko/2008061004 Firefox/3.0 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/2008062706 GranParadiso/3.0.1pre What keyboard command am I suppose to use to access these buttons? I used the tab button, and also typed the letters, but they still do not focus on the buttons.
Alt+O/V/I on Windows, Shift+Alt+O/V/I on Linux.
Is this not applicable on Mac? Verified fixed for Windows.
Yeah, I think it's still entirely keyboard inaccessible on Mac. Should file a bug about this if anyone cares.
Oh, we added "tabbable" on Mac, so you should be able to reach it with Shift+Tab from the search field or something like that.
(In reply to comment #43) > Shift+Alt+O/V/I on Linux. What “Shift”? Works with just Alt, including the second ru layout.
Hmm, tab-shift does not work. Neither does tab, alt-tab, nor ctrl-tab.
Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv
Component: Places → Bookmarks & History
QA Contact: places → bookmarks
You need to log in before you can comment on or make changes to this bug.