Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Map to Existing Roles #25

Open
aardrian opened this issue Jun 13, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@aardrian
Copy link
Contributor

commented Jun 13, 2019

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.

@aardrian

This comment has been minimized.

Copy link
Contributor Author

commented Jun 13, 2019

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

@jackbsteinberg

This comment has been minimized.

Copy link
Owner

commented Jun 25, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Jun 25, 2019

@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

This comment has been minimized.

Copy link

commented Jul 4, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.