I often see naive developers doing this:
<a href="" ng-click="...">Click me</a>
<div ng-click="...">Click me</div>
What would really be better is this:
<button ng-click="..." class="link">Click me</button>
<button ng-click="..." class="reset">Click me</button>
plus css styles to make the classes do the right thing.
However, it seems that this is too much to ask of developers. We are a lazy bunch and don't want to define new classes and reset styles for the sake of accessibility. To help folks out would be nice if ng-click automatically assigned the correct accessibility attributes if not already specified (role="button" tabindex="0") and handle all the right input handling (e.g. pressing enter, spacebar) to communicate to assistive technology that this element is actually a button , unless a role is explicitly specified already.
This would likely increase code size a little bit, so maybe it makes sense to put this extra logic into the ngAria module so that it is opt-in.
have you looked at ngAria at all yet?
Briefly but the documentation was a bit sparse last time I checked
OK, I found this line:
Where the tabindex issue is taken care of. That's the main one. Thanks!
Even better would be to automatically set an accessible role if one is missing.
@ewinslow the issue is that there is more than one role, and often more work required when a role is added.
@btford I actually think there is more work to be done on ngAria for tabIndex. Take this example:
ngAria will automatically add tabIndex because of ng-click, but it won't add ng-keypress. So to make it accessible from the keyboard we have to manually add it through Angular Material (we are dynamically adding roles and other properties). Does it make sense to also add ng-keypress as part of ngAria? The ideal thing would be to extend a native button, but without Web Components that isn't really possible.
@marcysutton points out an interesting question regarding keypress. I believe that it is in the accessibility specs that when user presses Enter or Space on focused element, the same thing should happen as if the element was clicked. If this is true, it makes sense to automate it in ngAria (or perhaps make it configurable).
@DmitryEfimenko that's only for native interactive controls such as button, anchor, or input. For elements that aren't interactive by default, such as div or md-button, even with tabindex="0" it does not fire click events from the keyboard. This is the same as vanilla JS/DOM behavior.
I am recommending we deviate from native behavior because of the use of custom element directives and ng-click. It's currently way too easy to implement inaccessible clicks, causing widespread accessibility problems.
feat(ngAria): Adds button role to ng-click
@DmitryEfimenko I've yet to think up a good reason to not use a real element when needed eg. button or anchor etc. and if I did I sure wouldn't sleep well that night :) But giving it some thought you could draw up a directive to handle such with ngAria: http://codepen.io/joe-watkins/pen/azzraM
feat(ngAria): add `button` role to `ngClick`