Closed
Bug 400703
Opened 17 years ago
Closed 17 years ago
Organize, Views, and Import and Export buttons not accessible via keyboard in Places Organizer
Categories
(Firefox :: Bookmarks & History, defect, P3)
Firefox
Bookmarks & History
Tracking
()
RESOLVED
FIXED
Firefox 3 beta4
People
(Reporter: MarcoZ, Assigned: dao)
References
Details
(Keywords: access, late-l10n)
Attachments
(1 file, 9 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Flags: blocking-firefox3?
Reporter | ||
Comment 1•17 years ago
|
||
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.
Comment 2•17 years ago
|
||
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.
Comment 3•17 years ago
|
||
(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+
Comment 5•17 years ago
|
||
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.
Reporter | ||
Comment 6•17 years ago
|
||
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.
Comment 7•17 years ago
|
||
Are they using click handlers on those elements? What kind of XUL elements are they?
Updated•17 years ago
|
Priority: -- → P2
Target Milestone: --- → Firefox 3 M10
Updated•17 years ago
|
Target Milestone: Firefox 3 M10 → Firefox 3 M11
Updated•17 years ago
|
Priority: P2 → P3
Updated•17 years ago
|
Blocks: fox3access
Assignee | ||
Comment 9•17 years ago
|
||
(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.
Comment 10•17 years ago
|
||
(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?
Reporter | ||
Comment 11•17 years ago
|
||
(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.
Comment 12•17 years ago
|
||
Seems like we need to work to try to get an owner for this.
Dao, would you be willing to take it?
Assignee | ||
Comment 13•17 years ago
|
||
Well, is making the buttons reachable with tab but not with accesskeys enough?
Comment 14•17 years ago
|
||
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)
Reporter | ||
Comment 15•17 years ago
|
||
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. :-)
Assignee | ||
Updated•17 years ago
|
Assignee: nobody → dao
Assignee | ||
Comment 16•17 years ago
|
||
Attachment #299771 -
Flags: review?(mano)
Assignee | ||
Comment 17•17 years ago
|
||
Assignee | ||
Comment 18•17 years ago
|
||
forgot to remove PlacesToolbar from places.xul
Attachment #299771 -
Attachment is obsolete: true
Attachment #299774 -
Flags: review?(mano)
Attachment #299771 -
Flags: review?(mano)
Comment 19•17 years ago
|
||
Hrm, did you test this on Mac?
Assignee | ||
Comment 20•17 years ago
|
||
No, sorry, I can't. I actually don't know what the expected look and behavior on Mac is.
Comment 21•17 years ago
|
||
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.
Reporter | ||
Comment 22•17 years ago
|
||
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.
Assignee | ||
Comment 23•17 years ago
|
||
excluding OS X this time
https://build.mozilla.org/tryserver-builds/2008-01-29_07:28-dgottwald@mozilla.com-1201620442/
Attachment #299773 -
Attachment is obsolete: true
Attachment #299774 -
Attachment is obsolete: true
Attachment #300052 -
Flags: review?(mano)
Attachment #299774 -
Flags: review?(mano)
Assignee | ||
Comment 24•17 years ago
|
||
Assignee | ||
Comment 25•17 years ago
|
||
Per beltzner, we want to keep the toolbarbutton appearance. I also added the dropmarker back, which he says would be minor but wanted too.
Attachment #300052 -
Attachment is obsolete: true
Attachment #300083 -
Flags: review?(mano)
Attachment #300052 -
Flags: review?(mano)
Assignee | ||
Comment 26•17 years ago
|
||
Comment on attachment 300083 [details] [diff] [review]
patch v2.1 -w
that's the version without the whitespace changes
Attachment #300083 -
Attachment description: patch v2.1 → patch v2.1 -w
Attachment #300083 -
Flags: review?(mano)
Assignee | ||
Comment 27•17 years ago
|
||
Attachment #300054 -
Attachment is obsolete: true
Attachment #300089 -
Flags: review?(mano)
Comment 28•17 years ago
|
||
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)?
Comment 29•17 years ago
|
||
Accesskey modifiers are subject to user prefs (hidden in about:config but documented):
http://kb.mozillazine.org/Accessibility_features_of_Firefox
Comment 30•17 years ago
|
||
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.
Assignee | ||
Comment 31•17 years ago
|
||
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.
Reporter | ||
Comment 32•17 years ago
|
||
(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.
Reporter | ||
Comment 33•17 years ago
|
||
(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.
Assignee | ||
Updated•17 years ago
|
Target Milestone: Firefox 3 beta3 → Firefox 3 beta4
Assignee | ||
Comment 34•17 years ago
|
||
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.
Attachment #300083 -
Attachment is obsolete: true
Attachment #300089 -
Attachment is obsolete: true
Attachment #300567 -
Flags: review?(mano)
Attachment #300089 -
Flags: review?(mano)
Assignee | ||
Comment 35•17 years ago
|
||
another Mac fix
Attachment #300567 -
Attachment is obsolete: true
Attachment #300612 -
Flags: review?(mano)
Attachment #300567 -
Flags: review?(mano)
Comment 36•17 years ago
|
||
Comment on attachment 300612 [details] [diff] [review]
patch v4
r=mano.
Attachment #300612 -
Flags: review?(mano) → review+
Updated•17 years ago
|
Keywords: checkin-needed
Comment 37•17 years ago
|
||
Comment on attachment 300612 [details] [diff] [review]
patch v4
late-l10n stuff needs explicit approval.
Attachment #300612 -
Flags: approval1.9?
Updated•17 years ago
|
Attachment #300612 -
Flags: approval1.9? → approval1.9+
Comment 38•17 years ago
|
||
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
Assignee | ||
Comment 39•17 years ago
|
||
Attachment #300612 -
Attachment is obsolete: true
Comment 40•17 years ago
|
||
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
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Keywords: checkin-needed
Depends on: 421529
Comment 42•17 years ago
|
||
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:1.9.0.1pre) 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.
Assignee | ||
Comment 43•17 years ago
|
||
Alt+O/V/I on Windows, Shift+Alt+O/V/I on Linux.
Comment 44•17 years ago
|
||
Is this not applicable on Mac? Verified fixed for Windows.
Assignee | ||
Comment 45•17 years ago
|
||
Yeah, I think it's still entirely keyboard inaccessible on Mac. Should file a bug about this if anyone cares.
Assignee | ||
Comment 46•17 years ago
|
||
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.
Comment 47•17 years ago
|
||
(In reply to comment #43)
> Shift+Alt+O/V/I on Linux.
What “Shift”? Works with just Alt, including the second ru layout.
Comment 48•17 years ago
|
||
Hmm, tab-shift does not work. Neither does tab, alt-tab, nor ctrl-tab.
Comment 49•15 years ago
|
||
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
Comment 50•6 years ago
|
||
Keywords: sec508
You need to log in
before you can comment on or make changes to this bug.
Description
•