feat: support bindings for the 'role' attribute - #630

FYI: @jelbourn

Also @marcysutton for input on the edge case behavior. I would think that for null/undefined/empty string, the attribute would be removed entirely and that for anything else it would be a warning or an error.

Agreed with @jelbourn and your original assessment. The browser mostly ignores bad role values...they fail silently, which is why it's so easy to get them wrong. If the framework could warn you when a role has an invalid value, that would be a huge benefit. Here's a little demo I made to test what the browser does:

http://codepen.io/marcysutton/pen/ogEwJM

If you accidentally passed a function instead of a string, the browser tries to make it into a string. In chrome://accessibility, the accessibility tree looks like this:

AXWebArea AXRoleDescription='HTML content' AXTitle='CodePen - Malformed Role Testing' AXEnabled='1' AXFocused='1' AXLoaded='1' AXRequired='0' AXURL='http://s.codepen.io/marcysutton/debug/ogEwJM?' AXVisited='0' AXExpanded='0' position=(0, 0) size=(1166, 514)
    AXGroup AXRoleDescription='function(){console.log('This' AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(1150, 16)
        AXStaticText AXRoleDescription='text' AXValue='You should feel bad' AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(130, 16)
    AXGroup AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(1150, 16)
        AXStaticText AXRoleDescription='text' AXValue='You forgot a role' AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(111, 16)
    AXGroup AXRoleDescription='group' AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(1150, 18)
        AXButton AXRoleDescription='button' AXTitle='Does this ruin a button' AXEnabled='1' AXFocused='0' AXRequired='0' AXVisited='0' AXExpanded='0' position=(0, 0) size=(140, 18)

If that function-as-value could throw a warning, that would be awesome. Empty values don't really hurt anything, as they just get the default role of that element.

One thing that could be super useful would be to warn when the developer uses an incorrect role (like role="image"), which happens a lot. But that list of valid roles could be the responsibility of ngAria or Protractor.

OK, so what I gather from the @jelbourn and @marcysutton comments is:

• null / undefined / empty role should remove the role attribute (keeping it wouldn't hurt, though)
• warn / throw on non-string roles (I believe that Dart version does it already)
• in the future it would be great to have a role verified against a white-list of allowed roles

Regarding the last point - @marcysutton is the set of roles "relatively fixed"? I mean - are we dealing with a small and finite list of roles described here that doesn't change much? If so we could think of white-listing this in a compiler, but protractor accessibility testing sounds like a very good / better idea. Maybe we should have a separate issues for this?

I'm going to modify the PR to:

• remove the role attribute on falsy values
• throw / ignore non-string attrs

@marcysutton could we handle roles white-listing in a separate issue when you decide if it should go to protractor and / or compiler?

@pkozlowski-opensource the list of roles is relatively fixed. The forthcoming accessibility integration for Protractor is a plugin that people will have to opt-in to, so if whitelisting of roles could be handled in the core framework and not as an add-on (like ngAria), it would provide huge value. I can create a separate issue for this.

@marcysutton great, thnx for the update. Yes, let's create a separate issue for this!

I don't know much about Angular 2.0 yet but what would be really useful for ARIA in general would be the ability to bind directives based on the VALUE of the attribute rather than the attribute itself. The reason for this is that there is a LARGE amount of functionality that each attribute value drags with it and you would not want to include all of that functionality in a single directive.

For an example of the functionality required simply for the menu role, see the following

https://github.com/dylanb/a11yfy/blob/master/a11yfy/jquery.a11yfy.core.js#L150

Lines 150 thru 420+ deal just with the menu role

Then from a validation perspective, if you could bind a directive to an element based on it matching either the value of an attribute, OR the name of an element OR a combination of elements and attribute names and values, you could build accessibility validation directives - which would be very useful.

@marcysutton have you created a separate issue yet? I have some comments I would like to attach to that.

@pkozlowski-opensource @dylanb here is the new issue, feel free to edit or add comments: #754

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}