Map to Existing Roles
Opened this issue · 5 comments
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:
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.
See #29 for why limiting to these roles can limit further implementation risks and challenges.
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.
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.
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 implicitaria-live
value ofoff
.
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.
To quote myself from above:
Can you share the screen reader testing results and materials?