400703 - Organize, Views, and Import and Export buttons not accessible via keyboard in Places Organizer

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P3)

Description

[Marco Zehe (:MarcoZ)]

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.

Comment 1

[Marco Zehe (:MarcoZ)]

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

[Aaron Leventhal]

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

[Mike Beltzner [:beltzner, not reading bugmail]]

(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.

Comment 5

[Aaron Leventhal]

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.

Comment 6

[Marco Zehe (:MarcoZ)]

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

[Aaron Leventhal]

Are they using click handlers on those elements? What kind of XUL elements are they?

Comment 9

[Dão Gottwald [:dao]]

(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

[:Gijs (he/him)]

(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?

Comment 11

[Marco Zehe (:MarcoZ)]

(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

[Aaron Leventhal]

Seems like we need to work to try to get an owner for this.

Dao, would you be willing to take it?

Comment 13

[Dão Gottwald [:dao]]

Well, is making the buttons reachable with tab but not with accesskeys enough?

Comment 14

[Aaron Leventhal]

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)

Comment 15

[Marco Zehe (:MarcoZ)]

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. :-)

Comment 16

[Dão Gottwald [:dao]]

Attachment: patch

Comment 17

[Dão Gottwald [:dao]]

Attachment: patch without whitespace changes

Comment 18

[Dão Gottwald [:dao]]

Attachment: patch v1.1

forgot to remove PlacesToolbar from places.xul

Comment 19

[Asaf Romano (gone)]

Hrm, did you test this on Mac?

Comment 20

[Dão Gottwald [:dao]]

No, sorry, I can't. I actually don't know what the expected look and behavior on Mac is.

Comment 21

[Asaf Romano (gone)]

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.

Comment 22

[Marco Zehe (:MarcoZ)]

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.

Comment 23

[Dão Gottwald [:dao]]

Attachment: patch v2

excluding OS X this time

https://build.mozilla.org/tryserver-builds/2008-01-29_07:[e-mail]-1201620442/

Comment 24

[Dão Gottwald [:dao]]

Attachment: patch v2 -w

Comment 25

[Dão Gottwald [:dao]]

Attachment: 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 26

[Dão Gottwald [:dao]]

Comment on attachment 300083 [details] [diff] [review]
patch v2.1 -w

that's the version without the whitespace changes

Comment 27

[Dão Gottwald [:dao]]

Attachment: patch v2.1

Comment 28

[Asaf Romano (gone)]

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

[Aaron Leventhal]

Accesskey modifiers are subject to user prefs (hidden in about:config but documented):
http://kb.mozillazine.org/Accessibility_features_of_Firefox

Comment 30

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 31

[Dão Gottwald [:dao]]

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.

Comment 32

[Marco Zehe (:MarcoZ)]

(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.

Comment 33

[Marco Zehe (:MarcoZ)]

(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.

Comment 34

[Dão Gottwald [:dao]]

Attachment: 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.

Comment 35

[Dão Gottwald [:dao]]

Attachment: patch v4

another Mac fix

Comment 36

[Asaf Romano (gone)]

Comment on attachment 300612 [details] [diff] [review]
patch v4

r=mano.

Comment 37

[Reed Loden [:reed]]

Comment on attachment 300612 [details] [diff] [review]
patch v4

late-l10n stuff needs explicit approval.

Comment 38

[Reed Loden [:reed]]

The places.xul changes have bitrotted. Mind attaching an updated patch for me, please, just so I can make sure I get everything?

Comment 39

[Dão Gottwald [:dao]]

Attachment: updated patch

Comment 40

[Asaf Romano (gone)]

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

Comment 42

[Hasham]

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.

Comment 43

[Dão Gottwald [:dao]]

Alt+O/V/I on Windows, Shift+Alt+O/V/I on Linux.

Comment 44

[Hasham]

Is this not applicable on Mac? Verified fixed for Windows.

Comment 45

[Dão Gottwald [:dao]]

Yeah, I think it's still entirely keyboard inaccessible on Mac. Should file a bug about this if anyone cares.

Comment 46

[Dão Gottwald [:dao]]

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

[[:Aleksej]]

(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

[Hasham]

Hmm, tab-shift does not work. Neither does tab, alt-tab, nor ctrl-tab.

Comment 49

[Gervase Markham [:gerv]]

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

Comment 50

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381