Snackbar: Update design documentation and add accessibility documentation.

[kjellr]

This PR adds design and accessibility guidelines for the Snackbar component. This is in addition to the development documentation (and very light design documentation) that existed previously. These guidelines are 'best practices' for the usage of the component, and they describe the component in more detail.

You can preview the updated document here:
https://github.com/WordPress/gutenberg/blob/fa16fa5f777af29958201b320185dc7601c349da/packages/components/src/snackbar/README.md

Thanks @drw158 and @sarahmonster for help drafting this. Looking forward to feedback from everyone! We'd especially love some feedback from folks on the accessibility team, on whether this covers the most important guidelines.

[senadir]

overall, following design guidelines depends on the team, while I'm onboard about the important of design, I'm not sure if we should:

1. remove code for the sake of following design, therefore not allowing anything multiple buttons or custom buttons
2. leaving the code as is and adding linter warning about it

[senadir]

this line conflicts with the code documentation on line 146

• actions: (array) an array of action objects. Each member object should contain a label and either a url link string or onClick callback function. A className property can be used to add custom classes to the button styles.

I kinda agree more with the design one, snackbar are meant to be informative and low priority, having multiple action would be confusing taking into account the 10s choice period.

while the design docs tells you what you should probably do, the code docs describe what exist and makes no assumption, so I think the actual code should be updated? @youknowriad @kjellr what do you think?

[youknowriad]

I think the code is as is to be consistent with the Notice component as with the core/notices package, you can just change the "type" of the dispatched action to switch between regular notices and snackbars.

So, I'm on the fence because consistency in APIs is a good thing as well. So I may be leaning towards keeping this as a guideline and not something strict in the API.

[kjellr]

This is a great point — thanks for raising it. From a design perspective, I think I'd prefer we were a little more strict about this sort of thing. Mostly because we know that 3rd parties will most certainly abuse the available options and create really distracting/confusing snackbars if we don't.

[youknowriad]

@senadir I think you can attempt a strict refactoring of the props. This would have impact on the notices package though :)

[senadir]

this also falls in the same area as the other comment, class names should not be available to customization because the button should not be customized

A className property can be used to add custom classes to the button styles.

[senadir]

@youknowriad, I can refactor the snackbar component if we're following the strict approach

[paaljoachim]

The PR was brought up during a Gutenberg Design Triage.
The document looks good, and seems ready to be included in the documentation.

@annezazu
Anne do you have any comments here?

[annezazu]

No major comments on my end except that I want to be sure proper accessibility feedback has been incorporated and everything is up to date especially since this is a year old. Otherwise, looks good to proceed with and can be iterated on in the future :)

[paaljoachim]

I am wondering if there should be a "undo" operation option?

For instance:
#17366 (comment)

[annezazu]

@critterverse thoughts on whether to just close this out or push forward and merge? I'm assuming these updates are still in line with current design thinking :)

[critterverse]

thoughts on whether to just close this out or push forward and merge? I'm assuming these updates are still in line with current design thinking :)

@annezazu Merging this makes sense to me! This documentation aligns nicely with the guidelines around snackbar usage in the WordPress Design Library.

[annezazu]

This was never moved forward and, two years on, I worry how out of date it is. I'm going to close this out as a result and encourage folks who want to continue working on it to open a new PR.