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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ng-click should do some helpful accessibility things by default #9254

Closed
ewinslow opened this issue Sep 24, 2014 · 7 comments
Closed

ng-click should do some helpful accessibility things by default #9254

ewinslow opened this issue Sep 24, 2014 · 7 comments

Comments

@ewinslow
Copy link
Contributor

@ewinslow ewinslow commented Sep 24, 2014

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.

@btford
Copy link
Contributor

@btford btford commented Oct 1, 2014

have you looked at ngAria at all yet?

@ewinslow
Copy link
Contributor Author

@ewinslow ewinslow commented Oct 6, 2014

Briefly but the documentation was a bit sparse last time I checked

@ewinslow
Copy link
Contributor Author

@ewinslow ewinslow commented Oct 6, 2014

OK, I found this line:

.directive('ngClick', ngAriaTabindex)

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.

@marcysutton
Copy link
Contributor

@marcysutton marcysutton commented Oct 17, 2014

@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:

<md-button ng-click="someFunction()">

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.

@DmitryEfimenko
Copy link

@DmitryEfimenko DmitryEfimenko commented Nov 25, 2014

@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).

@marcysutton
Copy link
Contributor

@marcysutton marcysutton commented Nov 26, 2014

@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.

marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Dec 4, 2014
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Dec 4, 2014
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Dec 5, 2014
@joe-watkins
Copy link

@joe-watkins joe-watkins commented Jan 10, 2015

@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

marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Feb 7, 2015
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Feb 7, 2015
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Feb 7, 2015
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Feb 7, 2015
marcysutton pushed a commit to marcysutton/angular.js that referenced this issue Feb 17, 2015
petebacondarwin added a commit that referenced this issue Mar 2, 2015
Closes #9254
Closes #10318
hansmaad pushed a commit to hansmaad/angular.js that referenced this issue Mar 10, 2015
netman92 added a commit to netman92/angular.js that referenced this issue Aug 8, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

6 participants
You can’t perform that action at this time.