feat: Add support for displaying toast-style notifications. #8896
Conversation
maribethb
requested review from
maribethb
and removed request for
rachel-fenichel
core/toast.ts
Outdated
| toast.dataset.toastId = options.id; | ||
| toast.className = CLASS_NAME; | ||
| aria.setRole(toast, aria.Role.STATUS); | ||
| aria.setState(toast, aria.State.LIVE, 'polite'); |
There was a problem hiding this comment.
I wonder if role alert and state assertive would be more appropriate? I'm not sure how aria decides when a polite notification should fire, but it would be unfortunate if the message goes away before it does, and it seems we are using the toasts to be more of an alert, i.e. you want to give immediate feedback that the keyboard shortcut didn't fire or something. https://sheribyrnehaber.medium.com/designing-toast-messages-for-accessibility-fb610ac364be
There was a problem hiding this comment.
I don't know; I assumed @microbit-matt-hillsdon had good reason for choosing these values though?
There was a problem hiding this comment.
I am curious to hear matt's thoughts, but you don't need to wait on this to merge
There was a problem hiding this comment.
I think the role is correct (at least for toasts in the general case), but there's a case to be made for assertive, and perhaps for it to be configurable on a per toast basis.
I'd review something like this with a good accessibility reputation and comprehensive implementation (support for > 1 toast is a jump in complexity though). In this case foreground toasts use "assertive" and I think a toast in response to a user action would be assertive. When we have blocks being read out it would be good to test in combination.
Tagging @kmcnaught too.
There was a problem hiding this comment.
Went ahead and made it configurable, defaulting to polite.
There was a problem hiding this comment.
Sounds good. I agree with role=status and polite or assertive depending on context (polite is a good default, but at some point we might want to add some examples to API docs to encourage platform developers from making good choices).
@microbit-matt-hillsdon let's start from the general policy that a toast confirming a user action (like "copied. press ctrl+v to paste") should be polite, where a toast explaining why a user action has failed (like "unable to copy this block" - hypothetically), should be assertive.
core/toast.ts
Outdated
| toast.dataset.toastId = options.id; | ||
| toast.className = CLASS_NAME; | ||
| aria.setRole(toast, aria.Role.STATUS); | ||
| aria.setState(toast, aria.State.LIVE, 'polite'); |
There was a problem hiding this comment.
I am curious to hear matt's thoughts, but you don't need to wait on this to merge
5 participants
The basics
The details
Resolves
Fixes #8824
Proposed Changes
This PR adds a basic implementation of toast-style notifications to Blockly. It also adds methods to
Blockly.dialogto show them, and to allow the implementation to be swapped out for an alternative by developers. The implementation is based on RaspberryPiFoundation/blockly-keyboard-experimentation#230.