-
Notifications
You must be signed in to change notification settings - Fork 27.4k
ng-click should do some helpful accessibility things by default #9254
Comments
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: Line 241 in c6d76d1
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
|
@marcysutton points out an interesting question regarding keypress. I believe that it is in the accessibility specs that when user presses |
@DmitryEfimenko that's only for native interactive controls such as I am recommending we deviate from native behavior because of the use of custom element directives and |
@DmitryEfimenko I've yet to think up a good reason to not use a real element when needed eg. |
I often see naive developers doing this:
What would really be better is this:
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.The text was updated successfully, but these errors were encountered: