Map to Existing Roles

[aardrian]

ARIA 1.2 contains roles that do not have native HTML counterparts, as outlined in 2.14 Aria roles and properties not available as features in HTML. A collection of roles that may apply to this proposal:

• alert
• log
• marquee
• status
• timer

Each of these roles identifies how it is exposed to the accessibility APIs and what states and properties they should expose.

For any of these roles that you feel applies to the proposed toast element, then you may want to mint attributes to indicate which (eg: type="alert|status|timer") and their associated ARIA states & properties (eg: live="polite|assertive" and/or atomic="true|false" and/or …).

At the very least, a native toast implementation should look to adopt one or more of these roles and follow the interactions already defined in the ARIA specification.

[aardrian]

See #29 for why limiting to these roles can limit further implementation risks and challenges.

[jackbsteinberg]

Thank you for creating an issue to discuss these, this has been really helpful for the accessibility research which is currently our highest-priority task.

After exploring these roles, the specs for alert and status seem to correspond best to the toast UI pattern. They have also been providing the best results in screen reader tests, including tests of existing toast patterns on the web. Between the two, we're still exploring which would work better in different contexts (e.g. in #18). We’re also exploring ways the timer role could be used to provide maximum benefit to non-sighted users.

More discussion on the distinctions between these roles and current ideas on how to use them in #18, #29, and #37.

[aardrian]

@jackbsteinberg

They have also been providing the best results in screen reader tests, including tests of existing toast patterns on the web.

Can you share the screen reader testing results and materials?

How did they provide the best results? Discoverability? Verbosity? Were the users skilled screen reader users? How did you recruit these users? What screen readers? What browsers? How were the tests structured? How did you measure success? How was the pattern implemented? …?

Having done research with users for years, forgive me if I am wary of trusting results without an opportunity to review the methodology, materials being tested, and final results.

[scottaohara]

i'm quite curious as to how timer would be useful here.

a timer being a:

numerical counter which indicates an amount of elapsed time from a start point, or the time remaining until an end point.

and

Elements with the role timer have an implicit aria-live value of off.

neither of which (a timing countdown, nor a live region that is not announced by default) being common expectations for a visible pop up message that is meant to communicate a small bit of information without interrupting a user's current action.

[aardrian]

@jackbsteinberg

To quote myself from above:

Can you share the screen reader testing results and materials?