1809747 - Create Bookmark popup disappears after 5 seconds

Status: NEW

(Firefox :: Bookmarks & History, defect, P3)

Description

[jasonzuvela]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:108.0) Gecko/20100101 Firefox/108.0

Steps to reproduce:

1. CTRL+D
2. Create New Bookmark popup opens.

Actual results:

After a number of seconds, the popup disappears by itself.

Expected results:

If I have mobility issues and it takes a long time for me to interract with my computer, such as it being physically difficult to move the mouse cursor in a steady, controlled and timely manner, or requiring other assistive technologies, then it would take a long time and many tries for me to reliably interact with the bookmark dialog window.

Largely, it would then be impossible for me to properly create a new bookmark, as the bookmark dialog window would always automatically close on me. This is both disheartening and extremely frustrating.

It is unacceptable as an accessibility issue, and precludes the normal use of this feature.

Please remove the auto-closing logic on the Create Bookmark popup.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Firefox::Bookmarks & History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Mark Banner (:standard8)]

Thank you for filing. As a possible work around, you could either press tab, or one of the arrow keys which would stop the timer occurring.

Comment 3

[Daniel Bodea [:danibodea]]

It is important to mention that when the CTRL+D hotkeys are being pressed, the bookmark is automatically saved in the last location where a bookmark was saved last and the user is not required to click the "Save" button unless information some being changed (name, location, tags).

Unfortunately, this is the user experience design chosen for this feature, however, there are many workarounds that you can choose to interact with the "Edit bookmark" dialog:

1. The method Mark has provided above: pressing the TAB or any ARROW keys after pressing CTRL+D keys to stop it from disappearing (unless clicking on anything else afterward).
2. The dialog can be opened again and again with the same hotkey (CTRL+D) or by clicking the "star" icon from the right side of the address bar.
3. When the cursor is placed beforehand where the dialog will open, it will also not disappear.

I will confirm this report as an enhancement and developers will decide if they can make changes to make this more accessible.
Thank you for your contribution!

Comment 4

[Marco Bonardo [:mak]]

We could evaluate exposing the timeout in about:config as an accessibility pref.
I think for accessibility reasons this may be considered a defect.

Comment 5

[Mike Kaply [:mkaply]]

I'm wondering if the accessibility pref should just not make it go away at all (or we can use some existing accessibility pref as a signal that it shouldn't be closed automatically)

Comment 6

[Chris Bellini (:cbellini)]

Hi Jared!

As part of bookmark experience improvements, would this be a good candidate to include as part of the investigation?

It's currently possible to disable the panel's display via a checkbox on it, and can be dismissed by clicking outside of it.

Comment 7

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Great idea. I'll ping Venetia to add this to the list

Comment 8

[James Teow [:jteow]]

We'll need input from UX to move forward. Do we extend the timeout and tie it to an accessibility preference (probably the simplest solution) or have a preference that disables the bookmark popup from disappearing altogether? Or maybe another heuristic from UX...

Comment 9

[Anna Yeddi [:ayeddi]]

(In reply to James Teow [:jteow] from comment #8)

We'll need input from UX to move forward. Do we extend the timeout and tie it to an accessibility preference (probably the simplest solution) or have a preference that disables the bookmark popup from disappearing altogether? Or maybe another heuristic from UX...

This is an accessibility issue that would affect accessibility of the panel and is failing WCAG 2.1 Success Criterion 2.2.1 Timing Adjustable - the panel remains opened for about 5 seconds only, while it is expected to allow users to have at least 20 seconds to perform one action (i.e. do one Tab key press for a keyboard-only or a switch device user). Besides the experience of the reporter, a user of a screen reader with slower screen reader speech settings would only hear that the panel is opened and the panel would collapse even before they may realize that there was, in fact, an option to customize the bookmark. This insufficient timeout would make the feature not discoverable/actionable for users with lower mobility, with cognitive difficulties, and users with low vision and blind users.

I'd note that we should not make users with impairments to go search for a pref (if they even are aware of it, i.e. users with cognitive and learning impairments would need to invest more time and effort in it as a power user without such impairments would), while a mouse user with faster mobility have access to this panel and its options available by default. I'd recommend to allow a pref to enable the disappearing. If a pref for larger timeout is created, we should provide an affordance to stop or adjust this timeout that is readily accessible for users (for instance, a doorhanger that does not disappear but is shown on the first interaction with the Bookmarks panel for all users, so someone with slower keyboard navigation speed and/or lower cognitive skills has enough time to 1. notice this panel, 2. read and understand what it allows to do, and 3. navigate to it and activate it to get to the pref). Still, I'd discourage this approach.

Let me know if I can help with any further work on this defect.

Comment 10

[Anna Yeddi [:ayeddi]]

After confirmation with the rest of the A11y team, increasing the accessibility severity to S2 as this panel UI disappears making its options inaccessible after an insufficient timeout. A similar example would be saving a file - in that case it is also requested by a user and Fx does not dismiss the dialog until the user explicitly confirms they want to do so (by saving or cancelling it)

Comment 11

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

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

For more information, please visit BugBot documentation.

Comment 12

[Marco Bonardo [:mak]]

I think the engineering priority is ok-ish, mostly because this is blocked on UX.

This is not actionable for engineering without having a direction... should the timer just be increased (though changing it to 20s as suggested by guidelines would make autohide quite pointless), or should we introduce an option to make the panel sticky? Or should it just stay until clicked outside?