1329643 - Tab key should only reach Remove button for active item in Container tabs list

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect, P5)

Description

[Marco Zehe (:MarcoZ)]

The preferences for the tab environments have an inconsistent keyboard and screen reader exposure problem.

First problem: The different items are in a list, but arrow keys don't actually work to navigate among the list items.

Expected: Arrows up and down navigate to the different items such as Shopping etc. Tab would move to the Preferences and Delete buttons for that item.

Actual: Arrow keys don't do anything, tab moves through all preferences and delete buttons.

Second problem: The items don't actually link to the buttons. A screen reader user only hears Preferences and Delete all the time while tabbing through that dialog, but not which button belongs to which item. The items themselves are mere labels that happen to be adjacent to the buttons, but other than visually, have no relationship to the buttons.

This dialog should work much like the list of add-ons in Add-On manager, where there are also buttons for each item, and one can select the individual add-ons via up and down arrows. Turning these into actual list items would also give better markup and a clear relationship between the items and their buttons.

Comment 1

[:Gijs (out for now; he/him)]

They are already in a <richlistbox> as actual <richlistitem>s. I don't know off-hand why keyboard navigation / a11y is broken.

Comment 2

[Jonathan Kingston [:jkt] he/him]

Reminding myself to look at this.

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change per https://bugzilla.mozilla.org/show_bug.cgi?id=1401020

Comment 5

[Jonathan Kingston [:jkt] he/him]

I'm going to clear the NI, it's not currently on my plate. I'm happy to work through this with anyone etc if they want to take it.

This looks like it's changed a little since the first STR in that arrows appear to act like tab.

Comment 7

[James Teh [:Jamie]]

The first problem reported in comment 0 appears to be fixed now: you can arrow up and down the list with no problems.

The second still exists: tab takes you through the remove buttons for each container, regardless of what container is active in the list. This is very confusing for a screen reader user and could potentially result in them removing the wrong container, which is pretty nasty.

This is similar to bug 1501897 and probably needs a similar fix; i.e. setting tabindex="-1" on buttons which aren't for the current item.

Comment 8

[:Gijs (out for now; he/him)]

Attachment: Bug 1329643 - implement generic richlistbox improvements for keyboard focus, r?Jamie

Rather than having each richlistbox consumer having to reinvent focus patterns for
buttons and menulists in its 'rich' items, let's just teach richlistbox and
richlistitem to not suck at keyboard navigation. That way we won't keep forgetting
to deal with this whenever we add new lists anywhere.

This allows us to remove the custom handling in sitePermissions.js, and the same
handling should be covered by the existing test, ie
browser/components/preferences/tests/browser_permissions_dialog.js

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/61377e7604a6
implement generic richlistbox improvements for keyboard focus, r=Jamie,settings-reviewers,mossop

Comment 10

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/61377e7604a6