Closed Bug 1329643 Opened 8 years ago Closed 2 years ago

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

Categories

(Firefox :: Settings UI, defect, P5)

defect

Tracking

()

RESOLVED FIXED
109 Branch
Accessibility Severity s3
Tracking Status
firefox53 --- wontfix
firefox57 --- wontfix
firefox109 --- fixed

People

(Reporter: MarcoZ, Assigned: Gijs)

References

(Blocks 1 open bug)

Details

(Keywords: access, Whiteboard: [userContextId][domsecurity-backlog] )

Attachments

(1 file)

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.
They are already in a <richlistbox> as actual <richlistitem>s. I don't know off-hand why keyboard navigation / a11y is broken.
Summary: Inconsistent keyboard navigation in Environmental tabs preferences → Inconsistent keyboard navigation in Container tabs preferences
Reminding myself to look at this.
Flags: needinfo?(jkt)
Whiteboard: [userContextId][domsecurity-backlog]
Priority: -- → P5
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.
Flags: needinfo?(jkt)
Severity: normal → S3

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.

Summary: Inconsistent keyboard navigation in Container tabs preferences → Tab key should only reach Remove button for active item in Container tabs list
Whiteboard: [userContextId][domsecurity-backlog] → [userContextId][domsecurity-backlog] [access-s3]

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

Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Pushed by gijskruitbosch@gmail.com: https://hg.mozilla.org/integration/autoland/rev/61377e7604a6 implement generic richlistbox improvements for keyboard focus, r=Jamie,settings-reviewers,mossop
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch
Whiteboard: [userContextId][domsecurity-backlog] [access-s3] → [userContextId][domsecurity-backlog]
Accessibility Severity: --- → s3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: