1875147 - Secondary action button (Settings icon control) on the autocomplete login is not accessible

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[Anna Yeddi [:ayeddi]]

Attachment: inaccessible-button-on-hover.png

The ac-secondary-action button within an autocomplete menu is not accessible:

1. It is not accessible with keyboard at all - the functionality that exists for a mouse and touch users is blocked for keyboard-only users, because it is excluded from the keyboard focus order with tabindex="-1" and there are no other alternative ways to navigate to it using keyboard alone
2. It lacks accessible name - assistive technology would render it as an unlabeled button and their users would not know what is the purpose of this control, even if they'll get to it
3. It is not visible by default - users with cognitive disabilities, neurodivergent users, users with autism, users with low vision relying on a magnification soft- or hardware, and others may not be aware that this control does, in fact, exist. They also may be confused when it would appear suddenly
4. The active area of this button overlaps with the active area of the richlistitem containing it - this may cause assistive technology like a speech-to-text software or alternative input devices like a switch control to send a click event on a wrong element, because technically both controls are clickable in the button's area. This may work with a specific set of assistive technology at the moment, but it is not expected to be working. It could affect touch users as well.

The first two issues - the lack of keyboard accessibility and the lack of an accessible name - are full blockers for the most of groups of disabled users.

This was captured with the a11y_checks failing toolkit/components/passwordmgr/test/browser/browser_preselect_login.js, thus when this issue is resolved, the fail-if notation should be removed from the test's manifest as well.

Comment 1

[Anna Yeddi [:ayeddi]]

I think, we could utilize arrow navigation, so the Up/Down arrows would move the focus between menu rows (by default, to the item), but then, when the row has focus (aka the menu item is focused), the settings button is visually shown (if issues #3 and #4 from the bug description are not yet resolved) and Left/Right arrows would move the focus from/to the Settings button and back to the menu item. At the very minimum, we want the Settings buttons to be hidden only visually (not programmatically) and, when the keyboard focus is moved on this control, it should become visible.

This navigation pattern was implemented, for example, on the Firefox View main area with a role=application on the container (this would signal to an assistive technology user about a custom navigation, that not only up/down moves are available).

Note on the button naming: while the button can be grouped with the control on the left, we could also use aria-describedby to refer to the on-screen text so each Settings button provides a context to the user.

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:serg, could you have a look please?

For more information, please visit BugBot documentation.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is set to S3. However, the accessibility severity is higher, .
:serg, could you consider increasing the severity?

For more information, please visit BugBot documentation.