User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID: 20180128191252 Steps to reproduce: 1. Open Firefox. 2. From the "View" menu, go to Toolbars -> Personalize. The "Personalize" page appears. 3. Use Shift+TAB to go to one of the following buttons in that page: "Themes" or "Density" and activate them with spacebar or ENTER. 4. In the pop-up menus that appear, use arrow keys, TAB, Shift+TAB, to move the keyboard focus in those pop-up menus. Actual results: You cannot select or change an option in those pop-up menus from the keyboard. Expected results: You should be able to select and/or change options in those pop-up menus via the keyboard.

While tab/shift-tab work for me to navigate the popup, there's no visual change in the popup so it's pretty unusable... When I run mozregression against this (tested on Linux), I see the same behaviour in 34, which is when this feature was implemented. However, the comments in bug 1007336 suggest that it should be keyboard-accessible. Jared, I know it's been 3 years, but any idea what's happened here? I'm also a little surprised this didn't come up when the density popup was implemented using the same styling etc. Johann, thoughts?

Yeah, this isn't great. I assume it works for screen readers, so it might not be that much of an a11y problem. CC'ing Marco just in case. I can't really explain why we didn't catch this earlier. I think I just didn't really think about this use case when I implemented the density popup, considering that I just re-used the existing popup code. This should have come up in some sort of QA (I know they test keyboard accessibility nowadays). We should fix this, but if my assumption is correct and this is not really an a11y issue I think P3 is a good priority for this.

(In reply to Johann Hofmann [:johannh] from comment #2) > Yeah, this isn't great. I assume it works for screen readers, so it might > not be that much of an a11y problem. CC'ing Marco just in case. Screen reader != a11y. Keyboard accessibility is a necessary thing even without screen reader use. I mean, there is a keyboard-accessible equivalent for the theme install / selection (ie about:addons), but I guess not really for the density popup. :-\

(In reply to Johann Hofmann [:johannh] from comment #2) > Yeah, this isn't great. I assume it works for screen readers, so it might > not be that much of an a11y problem. CC'ing Marco just in case. Oh, this whole panel is a big problem for screen reader users actually. It used to be better, so I don't know what changed, but the way it is now, much of it isn't really usable any more. :( > I can't really explain why we didn't catch this earlier. I think I just > didn't really think about this use case when I implemented the density > popup, considering that I just re-used the existing popup code. This should > have come up in some sort of QA (I know they test keyboard accessibility > nowadays). I don't actually find any of the menus inside the popup with the screen reader, so there's the keyboard navigability, and there's also the screen reader exposure. Maybe something in the late XBL removal work broke this, I don't know. > We should fix this, but if my assumption is correct and this is not really > an a11y issue I think P3 is a good priority for this. Considering the above, this is in fact pretty bad and deserves a P2, of not a P1 for this major breakage. :(

@Gijs, which platform did you test on? I just tested on Windows Firefox Nightly 60.0a1 (2018-02-09) (64-bit) and I see proper focus rects when tabbing through the Theme menu. The keyboard navigation here works great for me on the Theme menu, but is missing focus rects for the Density menu. The Theme menu uses toolbarbutton but the Density menu uses menuitem.

Ah, I see you said you were testing on Linux. I bet it is the difference between toolbarbutton styling on Linux vs Windows, and the Density menu not using toolbarbutton.

For what it's worth, here is a recording of the keyboard navigation on Windows: https://www.screencast.com/t/Yu5S3w6YkYH Sorry, it's in Flash.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6) > Ah, I see you said you were testing on Linux. I bet it is the difference > between toolbarbutton styling on Linux vs Windows, and the Density menu not > using toolbarbutton. This is odd because the OP is on Windows, too... Reporter, can you add more details about what you see if you tab/shift-tab through these menus? (In reply to Marco Zehe (:MarcoZ) from comment #4) > (In reply to Johann Hofmann [:johannh] from comment #2) > > Yeah, this isn't great. I assume it works for screen readers, so it might > > not be that much of an a11y problem. CC'ing Marco just in case. > > Oh, this whole panel is a big problem for screen reader users actually. It > used to be better, so I don't know what changed, but the way it is now, much > of it isn't really usable any more. :( This is pretty confusing, I don't think anything changed here recently. Can you check when this last worked? Is it obvious what is missing? We're just opening a panel anchored on the button. Perhaps we don't autofocus it or something? > > I can't really explain why we didn't catch this earlier. I think I just > > didn't really think about this use case when I implemented the density > > popup, considering that I just re-used the existing popup code. This should > > have come up in some sort of QA (I know they test keyboard accessibility > > nowadays). > > I don't actually find any of the menus inside the popup with the screen > reader, so there's the keyboard navigability, and there's also the screen > reader exposure. Maybe something in the late XBL removal work broke this, I > don't know. I would be very surprised if this had anything to do with recent work, see above. Please clarify what OS you're testing on and, if possible, when this regressed.

(In reply to :Gijs from comment #8) > Reporter, can you add more details about what you see if you tab/shift-tab > through these menus? Tab to navigate through a menu is a non-standard keyboard interaction. Menus are navigated using up and down arrows, plus right arrow to open sub menus, left arrow to close them, and Enter to select a menu item. In other words: Keyboard accessible != tab key does everything. And other menus of ours don't act this way, either, e. g. the page context menu, or the standard menu bar dropdowns. > (In reply to Marco Zehe (:MarcoZ) from comment #4) > > (In reply to Johann Hofmann [:johannh] from comment #2) > > > Yeah, this isn't great. I assume it works for screen readers, so it might > > > not be that much of an a11y problem. CC'ing Marco just in case. > > > > Oh, this whole panel is a big problem for screen reader users actually. It > > used to be better, so I don't know what changed, but the way it is now, much > > of it isn't really usable any more. :( > > This is pretty confusing, I don't think anything changed here recently. Can > you check when this last worked? Is it obvious what is missing? We're just > opening a panel anchored on the button. Perhaps we don't autofocus it or > something? Yes, autofocusing is one problem, after selecting the menu item from View/Toolbars, nothing is spoken, like no focus change. Only if I press tab do I suddenly get notified that focus is inside the panel. None of the items have any roles, so it is not obvious what to do with them. It is like tabbing through some span with text in it that has tabindex="0" set. And some ones, like the white space separators, even speak "unknown" when you tab to them, and only if I look at the children manually do I see a separator, and the explanatory text of white space. This is on Windows with NVDA. > > > I can't really explain why we didn't catch this earlier. I think I just > > > didn't really think about this use case when I implemented the density > > > popup, considering that I just re-used the existing popup code. This should > > > have come up in some sort of QA (I know they test keyboard accessibility > > > nowadays). > > > > I don't actually find any of the menus inside the popup with the screen > > reader, so there's the keyboard navigability, and there's also the screen > > reader exposure. Maybe something in the late XBL removal work broke this, I > > don't know. > > I would be very surprised if this had anything to do with recent work, see > above. Please clarify what OS you're testing on and, if possible, when this > regressed. I am in the middle of something else right now, so cannot look for a regression range, but especially the menu items don't speak for me eve when I press tab to navigate. But as I said above, that's not even a standard navigation paradigm.

Yes, I seam to be able to navigate via TAB and Shift+TAB in those two menus, but in order to move via UP and DOWN arrow keys i have to first move the focus inside the menus with Shift+TAB. Even so however, NVDA stays silent in those menus, although I can see the focus moving around in them.