Snackbar Accessibility Issues

[mapk]

I'm breaking out the a11y issues from https://github.com/WordPress/gutenberg/issues/16391 into this issue to make them more actionable and separate them from the other conversation. Thanks, @ryokuhi for getting this started!

Below is pulled from https://github.com/WordPress/gutenberg/issues/16391

Accessibility issues

• The Snackbar appears at the bottom left of the screen: this placement is out of view for users with limited vision field, users who use screen magnification, and users who zoom at high levels.

• The Snackbar disappears after 10 seconds, violating the WCAG requirement related to time-based operation (see https://www.w3.org/TR/WCAG21/#enough-time).

• Currently, the Snackbar is used only to show a message when a post is first published and when it's updated; while in the latter case the Snackbar is only a few tabs away from the update button, in the former case the Snackbar is very far in the DOM and, when using tabbing navigation, it's almost impossible to reach it before it disappears.

[mapk]

The Snackbar appears at the bottom left of the screen: this placement is out of view for users with limited vision field, users who use screen magnification, and users who zoom at high levels.

I just tested while zoomed in 300% and was still able to see the snackbar. It appears that at high zoom levels, the snackbar is still viewable, or am I doing something wrong?

I'm not sure how screen magnification works differently from zoomed in, but I'm happy to try testing this as well.

[afercia]

I'm not sure how screen magnification works differently from zoomed in, but I'm happy to try testing this as well.

Yep, it's different :) On a mac, you can try it via System Preferences > Accessibility > Zoom There's also a keyboard shortcut to toggle it, once activated: Option + Cmd + 8 Set it to: Zoom style > Full screen

This way the whole screen is actually limited to a small portion of the page.

[afercia]

Here: https://accessibility.blog.gov.uk/2018/05/15/what-we-learned-from-getting-our-autocomplete-tested-for-accessibility/ some accessibility testers using their setup, including screen magnification with Zoomtext (notice the entire screen becomes the "zoom window").

[mapk]

Yep, it's different :) On a mac, you can try it via System Preferences > Accessibility > Zoom

I gave it a go and it appears that this zooms to where your cursor is. Being that my cursor was over the "Publish" button that's where the screen was zoomed which did cause me to miss the snackbar notification completely.

When zoomed in while publishing, this is okay because I'm focused on the UI messaging which is a good indicator as seen in the image below. However, this doesn't apply to "Updates" or other messages that don't change the UI.

The older notification across the top did show some sort of UI change, which while wasn't clear what it was for when zoomed in, still indicated something happened.

[afercia]

Recommended reading from @scottaohara (Who is this guy?) about snackbars / toasts accessibility:

A toast to an accessible toast... https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html

Scott's post lists some of the considerations made also here, plus other interesting ones.

For completeness: there's a proposal from @jackbsteinberg (Google) to introduce a new HTML element for a "toast" pop-up notification, intended to be included in the Web Incubator Community Group (WICG) once it gets interest.

There's also a first GitHub issue about the new proposed HTML element accessibility by @aardrian 👋 https://github.com/jackbsteinberg/std-toast/issues/25

[afercia]

Special thanks to @NatalieMac for pointing the accessibility team at Scott's post.

[grahamarmfield]

Scott O'Hara also has a working 'toast' example that uses the HTML5 output element with minor attribute additions. This might obviate the need for a brand new element.

See https://scottaohara.github.io/tests/html-output/toastput-aria.html

[afercia]

From the same author, here's a good recap of the main accessibility concerns related to a "toast" (snackbar) component:

A toast to an accessible toast... Scott O’Hara – Jul 8, 2019 https://www.scottohara.me/blog/2019/07/08/a-toast-to-a11y-toasts.html

From the GitHub repo used to propose the standardisation and inclusion in HTML of a "toast" element (note: it's from Google)

Avoid Interactive Children https://github.com/jackbsteinberg/std-toast/issues/29

Adrian Roselli:

Anywhere in the DOM you place a toast that holds interactive controls will likely create both a reading order (1.3.2 Meaningful Sequence) and focus order (2.4.3 Focus Order) WCAG failure on a page/screen. At least not without a lot of native focus management supplemented by author focus management. We already know how difficult that is given the problems with native

implementations in browsers.

Scott O’Hara's feedback on accessibility of some existing "toast" implementations https://github.com/jackbsteinberg/std-toast/issues/29#issuecomment-501779286

Material's demonstration being good to show that the toast comes directly after the invoking element in the document order, so a keyboard user could get to the interactive control before a timeout. However, Material's toast could timeout while a keyboard focus was within the toast, which seems an oversight that should be avoided.

[sarahmonster]

Looks as though Dequeue has been working on a toast as well: https://pattern-library.dequelabs.com/components/toasts

Their three levels more closely correspond to how we are using Modal/Notice/Snackbar right now, but there may be implementation details there worth borrowing.

[paaljoachim]

We discussed it during a Design triage. https://wordpress.slack.com/archives/C02S78ZAL/p1585673618147600

We could move the snackbar notifications to the top center area (similar to other notifications). As it makes it easier for the user to notice the temporary alerts.

[aardrian]

Watching from afar (since I was mentioned) and am stumbling back here to share some more I have written on toasts in general and specific WCAG SC risks along with appropriate roles: https://adrianroselli.com/2020/01/defining-toast-messages.html

I cannot see the design triage nor do I know where to confirm you have discussed these already, so I will just drop them here:

WCAG 2.1 Success Criteria:

• 1.3.2: Meaningful Sequence (Level A)
• 1.4.4: Resize text (Level AA)
• 1.4.10: Reflow (Level AA)
• 2.1.1: Keyboard (Level A)
• 2.2.1: Timing Adjustable (Level A)
• 2.4.3: Focus Order (Level A)
• 3.2.4: Consistent Identification (Level AA)
• 4.1.2: Name, Role, Value (Level A)
• 4.1.3: Status Messages (Level AA)

UX cases that map to WCAG SCs:

• 1.4.13: Content on Hover or Focus (Level AA)
• 2.5.5: Target Size (Level AAA)

If you have already been through all these and satisfied them, then my apologies for adding noise.

Also, Adam Silver wrote a post a couple weeks ago that might help inform some decisions here: The problem with snackbars and what to use instead