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

Comments

Projects
None yet
6 participants
@ewinslow
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@btford

btford Oct 1, 2014

Contributor

have you looked at ngAria at all yet?

Contributor

btford commented Oct 1, 2014

have you looked at ngAria at all yet?

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Oct 6, 2014

Contributor

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

Contributor

ewinslow commented Oct 6, 2014

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

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Oct 6, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@marcysutton

marcysutton Oct 17, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@DmitryEfimenko

DmitryEfimenko 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 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

This comment has been minimized.

Show comment
Hide comment
@marcysutton

marcysutton Nov 26, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@joe-watkins

joe-watkins 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

@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

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