1872379 - The Password Manager Doorhanger is not gaining focus order when the panel is opened

Status: NEW

(Toolkit :: Password Manager, defect, P3)

Description

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

When the Password Manager Doorhanger is opened when the user is submitting their login form (i.e. after filling and pressing Enter/submit on https://fill.dev/form/login-simple), the keyboard focus stays on the web content and when pressing Tab the focus moves behind the Password Manager Doorhanger.

This makes it inaccessible for assistive technology users and especially for users of keyboard and other alternative input methods who has limited mobility or dexterity and would have to try to access the doorhanger with the keyboard with cumbersome traversal of the app, but the doorhager would disappear by then and they would have to also try to find how to re-activate this dialog. This may be even more difficult task for users with cognitive difficulties, with learning disabilities, for neurodiverse users, and for novice users too. It creates a blocker for these users.

The doorhanger should follow the ARIA Dialog design pattern - the focus should be moved to the doorhanger, when it's opened.

Comment 1

[BugBot [:suhaib / :marco]]

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

For more information, please visit BugBot documentation.

Comment 2

[BugBot [:suhaib / :marco]]

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.

Comment 3

[Sergey Galich [:serg]]

S3 feels right to me, user can focus panel as a workaround.
:ayeddi feel free to change if you think it should be S2.

Comment 4

[Masatoshi Kimura [:emk]]

I bet some users will complain about being "stealed" focus if this is implemented without an option.

Comment 5

[❌ Anna Yeddi [:ayeddi] ❌ On leave until 2027-01-04]

(In reply to Sergey Galich [:serg] from comment #3)

S3 feels right to me, user can focus panel as a workaround.
:ayeddi feel free to change if you think it should be S2.

The issue here would be that users may not become aware that the panel was opened. AFAIK, the panel is role=alertdialog which is only being announced when the keyboard focus is moved in it. If it’s an alert then the screen reader would announce the panel and its name - this would allow users to know that this panel was, in fact, opened and then navigate to it.

(In reply to Masatoshi Kimura [:emk] from comment #4)

I bet some users will complain about being "stealed" focus if this is implemented without an option.

For the doorhangers where it was a concern, we have implemented a check for the way the panel was opened: if it was done with the keyboard, then the focus is moved to the panel, if it was done with the mouse, then the focus is not actively managed.

I understand, in the case of passwords autocomplete the keyboard interaction is expected, but if we’re showing the panel on form submit, this may be the approach that would not prevent users with motor disabilities and users with limited dexterity from using this feature too, or not to make it very cumbersome to use. I’m happy to brainstorm ideas

Comment 6

[James Teh [:Jamie]]

(In reply to Anna Yeddi [:ayeddi] from comment #5)

The issue here would be that users may not become aware that the panel was opened. AFAIK, the panel is role=alertdialog which is only being announced when the keyboard focus is moved in it. If it’s an alert then the screen reader would announce the panel and its name - this would allow users to know that this panel was, in fact, opened and then navigate to it.

Most doorhangers get role alert by default and thus get read when they appear. If this is role alertdialog, this must be overridden somewhere specific to this particular doorhanger?

Note that our standard convention of f6 to focus the doorhanger should work here. If it doesn't, that's a bug we should fix.