Snackbar: Reduce the time messages display by half

[apeatling]

What?

The snackbar messages currently stay on the screen for 10 seconds. This PR reduces that time to 5 seconds.

Why?

This can often result in messages stacking up, even on flows where there's a lot of time between actions. See inserting patterns as an example of where the UI can be obscured because the snackbar messages stick around for so long.

How?

Reduce the NOTICE_TIMEOUT from 1000ms to 500ms.

Testing Instructions

Perform any action that initiates a snackbar display. Inserting a pattern or block is a good one.

Screenshots or screencast

This is 5 seconds -- notice how the snackbar message covers the button to show the pattern directory:

[andrewserong]

Thanks for opening this one @apeatling, the 10s often feels quite a bit too long to me, so I like the idea of exploring how we can reduce it. Just left a comment about what to do with cases where folks need to interact with the snackbar, or where we might have longer / more descriptive notices (and whether we should make the timeout configurable).

Also, since this proposes changing one of the components in the components package, it'd be good to add a changelog entry, too in packages/components/CHANGELOG.md.

[andrewserong]

Often snackbar notices might have a link in them that can be interacted with, e.g. if you save a draft, you can click to view the preview:

Would globally reducing the timeout make it harder for these interactive ones, or snackbars that contain more descriptive info? I'm mostly thinking of trying to ensure that users have enough time to read the snackbar, then make a decision about whether to interact with it, and then move the mouse over to the button and click on it. Would introducing a configurable timeout value help, so we could potentially preserve the component's default value of 10s, but then define a shorter timeout in specific usage?

[apeatling]

Ah yes, this is a good point! I don't think 5 seconds is long enough for interactive notices. I'd imagine also the reason they are 10 seconds. I think a configurable, or at least a context aware timeout is a better idea. 👍

[noisysocks]

One issue with making it configurable is that all of the timeouts will inevitably be inconsistent.

It does seem from looking into the history of this (#15594 (comment)) that 10s was fairly intentional:

Snackbar should disappear after a relatively longer period of time to allow people time to interact with them (10s) and should also be dismissable (even if via a non-visible action, like tapping on the snackbar itself) so as to ensure it doesn't get in users' way and allow for more choice.

[jasmussen]

How about 6 seconds as a starting point? I'd like to think that if the main purpose of the long delay is the "View preview" link in the snackbar, we can take that as a prompt to improve this area, which has a permanent link to it:

[jasmussen]

Speaking of, that really needs a little love:

• Legacy wp-admin focus style
• Too-dark disabled-gray input
• Inconsistent button sizes
• Inconsistent padding
• Just a lot, honestly, we can probably simplify drastically and reduce noise, borders, etc.

[apeatling]

@jasmussen I agree that sidebar view could improve, I'd actually be interested in working on that. The trouble is you don't see this when saving a draft of the post (when you get the View Preview snackbar). So it doesn't help in removing the need for it.

[apeatling]

Just taking a step back here a second. I think we could reduce the time to 6 seconds and get away with interactive notices still being usable, as mentioned by @jasmussen here. I will go ahead and do that.

Having said that -- the prompt for this change was to stop the snackbar from obscuring important UI positioned at the bottom of the left sidebar. With that context, is it worth revisiting a centre aligned snackbar that will eliminate (or dramatically reduce) this issue? There was a comment on it previously that didn't rule it out.

[github-actions]

Flaky tests detected in 5963980.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3941952000
📝 Reported issues:

• [Flaky Test] should always expand single line selection #39787 in specs/editor/various/multi-block-selection.test.js

[alexstine]

@afercia This may interest you for a review. Could this potentially hurt accessibility for low vision users?

[afercia]

@alexstine thanks for the ping. @andrewserong makes a good point: the timeout should be configurable.

The snackbars accessibility was discussed at length at the time of their introduction. They're not accessible, for many reasons. One of the reasons is that they disappear after a fixed interval. Assuming that 10 (or 5) seconds is enough time for all users is less than ideal. This applies not only to the snackbars that can be interacted with (the ones that contain links or buttons). It also applies to reading their content. Reference:

WCAG Guideline 2.2 Enough Time
https://www.w3.org/TR/WCAG21/#enough-time
Provide users enough time to read and use content.

So this isn't just a visual thing. It's also about interaction. It impacts many users: low vision, motor impairments, cognitive impairments, etc.

At the very least, the timeout should be adjustable on a per-user basis. Also, the ability to adjust the timeout should be clearly communicated to users: the feature should be easily discoverable, otherwise the a11y barrier would persist.

Also, the snackbars should be manually dismissible.

On a related note: the proposed change implicitly highlights the fact that the snackbars can be an obtrusive UI, in some cases. After a few years of usage, turns out the snackbars can be even annoying, for some users. I wonder whether the snackbars worth a complete rethinking.

[afercia]

@noisysocks would you mind if I request changes to this PR? I'm not sure reducing the timeout is the right way to go *see my previous comment).

[noisysocks]

@noisysocks would you mind if I request changes to this PR?

I believe you just did 😀

[noisysocks]

Also, the snackbars should be manually dismissible.

Just noting quickly that snackers are dismissible by clicking on them. (Probably an X icon would be more discoverable.)

[afercia]

Just noting quickly that snackers are dismissible by clicking on them. (Probably an X icon would be more discoverable.)

That's an interesting example of markup.

<div class="components-snackbar" tabindex="0" role="button" aria-label="Dismiss this notice">
    <div class="components-snackbar__content">
        Draft saved.
        <a href="http://localhost:8889/?p=5244" class="components-button components-snackbar__action is-tertiary">View Preview</a>
    </div>
</div>

Basically this is equivalent to putting a link inside a <button> element. Not to mention the aria-label overrides any textual content within the role=button:

Material for a new issue.

[apeatling]

Basically this is equivalent to putting a link inside a element. Not to mention the aria-label overrides any textual content within the role=button:

@afercia What would be the ideal markup here?

[apeatling]

Closing this one in favour of #47298 which addresses the original concern more clearly.

[afercia]

Basically this is equivalent to putting a link inside a element. Not to mention the aria-label overrides any textual content within the role=button:

@afercia What would be the ideal markup here?

Hm, one that separates the three important things:

• The snackbar text.
• The Dismiss button.
• The action link.

I do realize that would require some good refactoring of the Snackbar. The underlying semantics / accessibility issues have been discussed at length at the time of the introduction of the Snackbar component and they're still unsolved for the most part. I'm not willing to cycle back to those discussions. Just noting there are still pending issues to solve.