Add language to http://ampersandjs.com/learn/role-attribute to discuss accessibility implications

[wraithgar]

Assigning certain role attribute values to some elements affects the way accessibility readers present your UI to the end user.

http://rawgit.com/w3c/aria-in-html/master/index.html#what-does-adding-a-role-do-to-the-native-semantics

It would be nice to at least mention this in the learn page, and hopefully even go into some best practices (if some can be determined)

[dobbs]

Hey @AmpersandJS people. This issue is important. The basis of your recommendations for using a role attribute are sound -- preventing collisions between devs and designers in use of id and class attributes. The problem is that role is important for ARIA: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA

A better solution is to recommend data-* attributes. On one hand they can name the attribute in semantically meaningful ways. More importantly they enable people to use role in support of making their web apps helpful to people with screen readers or other assistive devices. As it is now, you are steering people in a direction that can discriminate against people with disabilities.

For your own code, find and replace role with data-role and then rewrite that page to be about "The humble data-* attribute". jQuery won't notice the difference if your selectors change from [role=anything] to [data-role=anything]. And same goes for the HTML markup.

[wraithgar]

Related: http://www.w3.org/wiki/PF/XTech/HTML5/RoleAttribute#ARIA_1.0_Pre-Defined_Roles (ARIA reserved roles)
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes#data-* (definition of data- under the context of use by scripts)

[HenrikJoreteg]

We most certainly don't want to cause problems for accessibility. My question currently is just if it's better to avoid using them or to add as much semantic value to the doc as possible?

There's a potentially nice overlap in this, in that JS also cares about the element's purpose in the app.

So, perhaps encouraging people to use it may actually be a net gain in accessibility where most won't add roles at all otherwise? If we could accomplish that, that'd be awesome.

If it turns out that's not the case we'll certainly change the recommendation.

I'm still looking for a definitive resource or expert in how they're actually used for accessibility.

Help in figuring this out would be much appreciated.

[wraithgar]

@HenrikJoreteg this is the resource we were trying to find http://www.w3.org/wiki/PF/XTech/HTML5/RoleAttribute#ARIA_1.0_Pre-Defined_Roles
It outlines explicitly the ARIA 1.0 pre-defined roles that are considered 'reserved'. As you can see it's not a small list, and has a section at the end for extendability too.

I'm personally of the mind that in that light, and after re-reading the html definition on data- http://www.w3.org/TR/html5/dom.html#custom-data-attribute and seeing how it's explicitly not to be interpreted by anything outside the site itself, we should be using data- instead of role.

[dobbs]

My gut feeling is to think of ARIA as another separate concern. So let the CSS work from id and class, let the javascript work from data-* attributes, and let ARIA stuff work from role and the various aria-* attributes.

I've been using data-* attributes for binding DOM to javascript in various production environments for several years now. I haven't done anything directly with ARIA. I learned about ARIA while investigating the Fluid Infusion project:

http://fluidproject.org/products/infusion/
https://github.com/fluid-project

They seem to be quite serious about an inclusive web. Google seems to think Mozilla's pages on ARIA are the place to start, but I think you might find the code in Infusion worth looking at. And perhaps it will be a case where Ampersand proves flexible enough to use Fluid components in the view to gain the benefits of their thinking on accessibility and inclusiveness.

[latentflip]

On a quick glance, I'm +1 on shifting the recommendation from role to data-, and updating getByRole in ampersand-view appropriately, as well as the various role selectors in, eg ampersand-dom-bindings.

Given the wide range of roles already defined, and their use in accessibility, it doesn't make sense to me to try and compete with their use. Given how generic the roles are, it also doesn't make sense to me to try and overload them by trying to use them for both accessibility and js hooks.

The question then is what should we switch to? The benefits of role were:

• It's short, and easy to remember
• It was always the same attribute name - the trouble with data-* is that it's easy to get creative with the attribute name which leads to inconsistency.

data-role="foobar" would be the obvious alternative, but that feels a bit weird as it's kinda confusing with role now, and getByRole gets more confusing.

this proposes data-js, which has the benefit of being clearly related to JS, and is fairly short. Though, I don't know what you'd rename getByRole and the role shortcuts in ampersand-dom-binding to?

[kamilogorek]

+1 for data-js but as you said, to quote classic: “There are only two hard things in Computer Science: cache invalidation and naming things”

[wraithgar]

I agree w/ the data-role feeling like it was an arbitrary decision that's based on the practice of having used role before.

data-& is unfortunately invalid html :/

Without haven given much thought (so heads up on that) I feel like if we go with data-js the function becomes getByDataJs(foo) or getByData('js', foo)

[wraithgar]

The nice thing about this is we can leave getByRole so as not to break anyone using that in production. REMOVING getByRole imo can be a totally different discussion i.e. do we deprecat now, do we have a timeline goal?

[kamilogorek]

getByData might be kinda confusing, as people may think that it refers to "data" itself, not data attribute.
About getByData('js', foo), I agree with @latentflip that people can get sometimes too "creative".

[fampinheiro]

Just my 2 cents. getByData('js', foo) may become very tiresome after a while, writing js every time you want to bind something, I kind of prefer a more specific approach like getByDataJs(foo)

Just for the sake of creativity getByJsTag(foo), getByJsRole(foo) or getByJsNode(foo).

[legastero]

Some pondering I've gone back and forth on about this issue:

1. There have been instances where I've wanted to be able to reference an element via multiple "roles", mainly for some views where the template was user supplied and some features conceivably could exist on either a single element or multiple.
2. The spec for the role attribute says that it is actually a space separated list of values (of which the browser uses the first one it recognizes for ARIA purposes).

So, I'd like for any getByX() method to support picking out the given value from a list. In which case, what if we made getByRole() pick an element that contains the given value in the combined set of role and data-role values?

[prust]

It's short, and easy to remember
It was always the same attribute name - the trouble with data-* is that it's easy to get creative with the attribute name which leads to inconsistency

+1

FWIW, data-js doesn't appeal to me; I would prefer data-role (though that would imply getByRole() which wouldn't allow them to live side-by-side) or data-name (which may be confused w/ the name attribute, but at least it's less confusing than data-id).

[prust]

A few more options from the synonym finder: title, tag, label, moniker, handle. Most of those are already used in HTML, of the ones that aren't, I like data-handle the best...

[latentflip]

Great thoughts @legastero, 👍 on whatever solution supporting multiple roles. We can do that with [data-role~=logged_in] [role~=logged_in] or whatever.

Also, on @legastero's point about role allowing multiple attributes, I'm intrigued as to what the potential fallout of using non-aria roles in role is? I guess the concern is future collision, but that feels like a minor concern. Which I guess is back to @HenrikJoreteg's question of whether it's still actually okay to still use role, and just teach people how to also add proper accessible roles where it makes sense.