Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Avoid Interactive Children #29
Looking back through the readme, I see the following:
That behavior is a dialog, not a toast.
Note that the ARIA roles I have identified in #25 (Map to Existing Roles) generally do not have interactive controls within them (other than to dismiss). They are informational.
Those roles generally do not receive focus when they appear nor should they. Adding interactive controls creates a more complex challenge, especially as I see other issues discussing where a toast should live in the DOM.
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
If the toast has a built in time limit before it disappears, then adding interactive controls means the browser must also provide a way, via settings, to override that time limit. Otherwise it will create 2.2.1 Timing Adjustable challenges for authors and users.
To recap, allowing toasts to contain interactive controls puts the burden on the user agent to:
Did you see the research? https://github.com/jackbsteinberg/std-toast/blob/master/study-group/. It turns out it's quite common for toasts to have at least a close button, and often an action button.
But yeah, it's of course a hard requirement that such actionable toasts are accessible and WCAG conformant, as they are all on all native platforms, and in at least some of today's web libraries. Thanks for pointing out specific ways toward ensuring that!
I did. It was part of the reason I opened this issue (though I failed to cite it). So while it may be common for toast implementations to have some sort of action button, that does not make it a good pattern nor one that must be emulated.
However, if allowing nested interactive controls (outside of a dismiss control) is defined as in scope for this proposed element, then we may be better off shelving this and revisiting
Going to echo support for this issue.
Outside of a close button which could be useful for sighted mouse/touch to dismiss a toast more quickly, the timed behavior of a toast message can make these components difficult for some people to navigate to, and can be frustrating if important interactive controls are used within. While it may be common to see such patterns in the wild, it doesn't mean it provides good inclusive user experiences. Often when evaluating the accessibility of applications, such interactive controls used within timed-toasts are issues that get brought up for remediation.
Taking a look through the researched examples of toasts or toast-like elements that "mentioned accessibility" the ones that had the best documentation or most closely resembled the functionality that would match the ARIA roles listed in #25 were Bootstrap, and Notyf. These did not have child interactive elements in their demos, outside of a dismiss button in Bootstrap's.
Material UI and Sales Force had examples of toasts with child interactive controls. 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. Sales Force's toasts were all static when looking at their example page.
Sweet Alert 2 is a dialog pattern, so not really applicable here.
BlueprintJS has a general accessibility statement, but nothing relating to their toasts. Invoking a toast produced no announcement of the message, and their option to auto-focusing the toast should be avoided, as you'd be getting close to modal/non-modal dialog behavior by doing that.
While not flagged as mentioning accessibility, Polymer's toast appeared to be a demonstration of how I'd expect a native toast to behave as well, though in testing it did produce some duplicate announcements...but that could easily be sorted out.
Is it accurate to say that a toast is not a dialog because a dialog inherently requires a user interaction (e.g. "click yes or no"), and that a toast does not require a user interaction? Even if it has the option for one? Just want to make sure there's clarity about why a toast isn't just a slightly different approach to a dialog, especially if they can contain user interactions.
Compare with the status role (a scenario where framework toasts are used):
Maybe instead of the matrix (table) comparing features from the assorted frameworks, we should be looking at one comparing the assorted standards-defined roles — which have accessibility built in already and are at least on track to be implemented by browsers and AT.
No time today for a PR (because this is not my day job), so I will have to sit on this for now.
Within the time I took to research existing toast implementations I didn’t spend the time accessibility testing each, and now that I am creating a more in-depth accessibility study I appreciate the follow-up on this particular concern. The research was largely focused on gauging what functionality toast libraries provide, as a way of understanding how they’re used on the web in general. And from that research it seems that placing an action on an ephemeral pop-up notification is a pattern that UX developers seem to often desire from their toast implementations. With this proposal we’re trying not to rescope what developers consider to be a toast, but to instead implement an element that follows the existing patterns in a way that’s accessible for all. If we can’t build a standardized toast for all users, then developers will continue to use imperfectly accessible solutions, and certain swathes of the web population will miss out on features that make the web a richer application environment.
With that said we’re going to be concentrating efforts on designing the accessible action-toast experience as best we can, with helpful community feedback like this issue. This is our current idea of what that looks like:
In combination with some further accessibility efforts, such as exploring the best solution for default timeout, we’re hoping this model will allow us to create a maximally accessible toast. We’re also hoping that this will be feasible with current web technologies and accessibility patterns, and these comments have been very helpful in providing benchmarks to check our accessibility solutions against. This is all still under iteration, and further help / input on how to build such an intuitive, inclusive toast is very much welcomed :)
Thank you for mentioning the
As far as the distinction between
This was referenced
Jun 25, 2019
Big red flag here. Are you suggesting the toast is going to steal focus?
HTML already has a
I left thoughts about the types on #18 (comment).
But here you are weaving together multiple issues (time-out, focus, announcements) and (I suspect) making an assumption about what would be useful for a screen reader user.
If there is a control and screen reader user must take action, then avoid the time-out, steal focus, and make an
If you agree it is a fit, then it is probably outside the scope of toast and belongs with the native