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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Role attribute and WAI-ARIA specs #6

Closed
RenanOliv opened this issue Sep 28, 2016 · 3 comments
Closed

Role attribute and WAI-ARIA specs #6

RenanOliv opened this issue Sep 28, 2016 · 3 comments

Comments

@RenanOliv
Copy link

The idea of making JS behaviors more understandable by using the role tag is really neat. 馃憤

But it conflicts with the current W3C WAI-ARIA 1.0 specification. Mostly this normative regarding the usage role of the attribute . In short the specs already categorizes roles that define user interface widgets and page structures.

So the following example would be incorrect by the specs:

<div class='user-info' role='avatar-popup'>...</div>
$('[role~="avatar-popup"]').on('hover', function() { ... });

But this one would not:

<div class='user-info' role='contentinfo'>...</div>
$('[role~="button"]').on('hover', function() { ... });

In the end the usage of the role attribute is not conceptually wrong by W3C definition:

Main indicator of type. This semantic association allows tools to present and support interaction with the object in a manner that is consistent with user expectations about other objects of that type.

Possible solutions

It is possible to keep using the role attribute but restricted it to WAI-ARIA roles: Solving the JS behaviors bound selectors abstraction dilemma and making the code compatible with screen readers. But would make impossible to create more than one selector for specifics behaviours.

The only solutions I see is either by using custom data attributes in a fancy way or by creating an specific class naming schema.

@rstacruz
Copy link
Owner

rstacruz commented Sep 28, 2016

Thanks for the well thought out comment. It may be time to demote the role
guidelines in rsjs in favor of .js-* class names (but maybe keep the role
guidelines as an aside).

@rstacruz
Copy link
Owner

rstacruz commented Sep 28, 2016

(worth noting: I think the most practical conflict here is when you want to
actually attach a role attribute for screen readers, and also attach Js
behaviors to a component.)

@rstacruz
Copy link
Owner

rstacruz commented Oct 7, 2016

Moving forward, the new recommendation will be to use data-js attributes.

<!-- ok -->
<div class='user-info' data-js-avatar-popup>...</div>
$('[data-js-avatar-popup]').on('hover', function () { ... })

You may also add values to these attributes for more control... something the role convention previous did not allow for.

<button data-js-tooltip='Close'>...</button>

Thanks for your help!

@rstacruz rstacruz closed this as completed Oct 7, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants