Boom toasted #27155

Lausselloic · 2018-08-30T14:58:46Z

Hello, @Johann-S
I've improve some part of the toaster

improve accessibility by adding role="alert" aria-live="assertive" aria-atomic="true" on samples and write some more details onto how make it more accessible (maybe need an english review @patrickhlauke )
also for accessibility, I think it's really better to let user control the toaster and close it by itself (otherwise AT will vocalise the content but the user can't find it into the page) maybe need a way to inform the user with AT that's an autoclosed component? Haven't find a good idea with aria :-(
update the hide method to close toaster immediatly on click, implement data-dismiss="toast" like for modal
add a unit test for that purpose

…nents - implement data-dismiss="toast" to easily create a non-autohide toast and allow user to interact itself with the component

…al close actions. By this way could be call when user click on close button

…ete method otherwise shown event is thrown before event is attached. Also add a param to hide method, if withoutTimeout=true then don't set the timeout and call close. Otherwise call close after the timeout

…, and attach listeners in constructor

Johann-S

JS part looks good to me 😉

patrickhlauke · 2018-08-30T15:21:54Z

x-ref #22980

patrickhlauke · 2018-08-31T08:50:31Z

just on the aspect of having buttons to explicitly close a toast - this kind of mixes up the difference between toasts and proper alerts i think.

toasts are generally small announcements that then disappear - they're given aria-live so that they get announced without shifting the user's accessibility/keyboard focus. making them stay and expecting user to close them makes them...not a toast, but an alert of sorts. normally, alerts get focused, but i gather in this changed version they don't, so IF a user wanted to close them, they'd have to navigate the whole page before reaching the close button? if so, it seems a bit of a mixed-up approach (not necessarily wrong, but not a classic toast)

xref https://www.w3.org/TR/wai-aria-practices-1.1/examples/dialog-modal/alertdialog.html

patrickhlauke

A few tweaks to the prose, but I'm not 100% sure about the fundamental "don't autohide them" take

patrickhlauke · 2018-08-31T08:52:39Z

site/docs/4.1/components/toasts.md

@@ -88,10 +100,12 @@ Plus, they'll easily stack.
 ## Accessibility

 Toasts are intended to be small interruptions to your visitors or users, so to help those on screen readers, you should wrap your toasts in an [`aria-live` region](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions). This allows screen readers the ability to see suggested interruptions without any visual cues.
+To improve accessibility level, we strongly recomend to use `autohide: false` and add a `close` button into the header to let user dismiss that element.
+You also need to adapt the `role` and `aria-live` level depending on the content. If it's an important message like error, use an `alert` role `assertive` otherwise use a role `status` with a `polite` level. 


may be more terse and unambiguous at the end to say:

...use role="alert" aria-live="assertive", otherwise use role="status" aria-live="polite"...

patrickhlauke · 2018-08-31T08:55:02Z

site/docs/4.1/components/toasts.md

@@ -88,10 +100,12 @@ Plus, they'll easily stack.
 ## Accessibility

 Toasts are intended to be small interruptions to your visitors or users, so to help those on screen readers, you should wrap your toasts in an [`aria-live` region](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions). This allows screen readers the ability to see suggested interruptions without any visual cues.
+To improve accessibility level, we strongly recomend to use `autohide: false` and add a `close` button into the header to let user dismiss that element.


"to let users" (plural i'd say)"

Also, I wouldn't say it's necessarily an accessibility improvement. toasts/notifications that appear, are announced, and autohide are common and well supported by AT. there ARE some aspects, like users with cognitive disabilities or users that employ screen magnification without AT capabilities that may have issues with toasts, but that's a much larger discussion than just saying "don't hide it". those users would generally benefit more from explicit alert dialogs rather than toasts (dialogs that are modal, and shift focus to the dialog, etc)

…the component (#27155)

Lausselloic · 2018-08-31T09:21:37Z

Hello @patrickhlauke thanks for your feedback. You're right on ambiguity between toasts and alert
So maybe we could "allow" but not strongly recommend to use a close button on a toaster, just to have a customizable component, and after for accessibility purpose :

For cognitive disabilities, and screen magnification : maybe add a section into the doc to Warn about the timeout importance of the toast depending on the content? Explain that to fit all users need, developper need to specify a timeout that allow "low speed readers" to read it, and if the information is "critic" for the process like "fix all the errors in the form before submitting again" then use an alert component instead of a toast

And I agree that screen reader will works like a charm just with aria-live and no need of close button

patrickhlauke · 2018-08-31T09:26:07Z

@Lausselloic "maybe we could "allow" but not strongly recommend" yup sounds like a fair compromise
(hoping my quickfire comments didn't come across as too brusque ... haven't had enough coffee yet ;) )

Lausselloic · 2018-08-31T09:44:13Z

I've not been hurt by your comment, by the opposite it's a pleasure to have structural debate arround accessibility :-)

…the component (#27155)

…e button everywhere just let it when autohide is set to false