ngAria bindKeypress: IE9/IE11 doesn't fire some 'keypress' events on DIV, LI

[kkoskelin]

Dear ngAria/a11y Angular devs,

I'm working on developing a highly accessible application in which Internet Explorer 9 (and eventually IE11) will be the primary browser target. In our application we've included the ngAria module, but have found that even though we can use keyboard navigation, not all keyboard events fire as expected in IE9/IE11.

Because of ngAria's bindKeypress configuration, ngClick items also can get identical bindings for the 'keypress' event. This works great in Chrome where I've tested it. But if the elements are one of DIV, LI the keypress event does not fire for the ENTER key in IE9/IE11.

Fiddle demonstrating this behavior: http://jsfiddle.net/kkoskelin/ag8hcknz/

Angular Versions tested: 1.3.14, 1.4.0-beta.5
Browser/OS: Internet Explorer 9 + Windows 7, Internet Explorer 11 + Windows 8.1

Suggested fix: Internet Explorer 9 will fire the keydown event. This is also shown in the fiddle above. I've also tested by altering my local copy of angular-aria.js and changing the 'keypress' binding to 'keydown' at line 336 of
https://github.com/angular/angular.js/blob/master/src/ngAria/aria.js#L336
such that it reads
elem.on('keydown', function(event) { ...

I've attempted to use $provide.decorator to alter the directive's behavior but haven't had any success.

[ericsorenson]

👍

[andrewaustin]

I tested this in IE10 (10.0.9200.17183) and can confirm the reported behavior.

Another thing I noticed is that the keypress event does fire if you select the li/div with SPACE instead of ENTER.

[kkoskelin]

@andrewaustin you are correct. The ngAria bindkeypress feature is listening for both SPACE and ENTER, but only SPACE ever triggers the event.

[Narretz]

Have you guys tested with Firefox? Seems to be the exact other way round compared to IE: space does not work, enter works.

[kkoskelin]

@Narretz confirmed your described behavior on Firefox 36.0.1 on OSX. Presumably we want both of these keys triggering the key(press|down) events. Thanks!

[andrewaustin]

@Narretz @kkoskelin The firefox issue is entirely different.

In firefox, a keypress event triggered from a printable character does not populate event.keyCode, but instead populates event.which. I have a fix (and unit test) for this in #11340.

The IE issue is more tricky. A keypress event handler is getting added to the <li> and <div>, but for some reason it is not getting fired. You can see from http://jsfiddle.net/937krogo/ that IE9-11 does fire the keypress event on both SPACE and ENTER, so more investigation is needed.

(edited: provided link to jsfiddle rather than jquery docs)

[kkoskelin]

@andrewaustin I think that the keypress events are being handled differently in IE when attached to non-form elements such as <div> or <li>, specifically when it comes to "special keys" such as ENTER.

Though I don't currently have an instance of IE in front of me, I've forked the original fiddle to add some jQuery listeners here:
http://jsfiddle.net/kkoskelin/j1xgnL73/

This is about keypress vs keydown events in IE when attached to non-form elements such as DIV and LI. It doesn't matter whether you're using jQuery or Angular in that case as it comes down to native event listeners for 'keypress' and 'keydown' on these elements.

[andrewaustin]

@kkoskelin The last fiddle I shared demonstrates that that is it not an issue with IE event handlers being treated differently when attached to non-form elements.

It looks to be an issue caused by the buttons on the page. Check out your example with the buttons removed, which works perfectly in IE11: http://jsfiddle.net/1gt44u0o/

[kkoskelin]

Yikes... You're right.

• If a button is present, the ENTER key (via keypress) doesn't register on the first two LI elements.
• If the button is within a <form>...</form> (and LI elements are outside the form), ENTER via keypress registers correctly on the first two LI elements. http://jsfiddle.net/rw9q8cqz/
• If all elements are within a <form>...</form>, the ENTER key will trigger the keypress event but the focus is then immediately given to the button. http://jsfiddle.net/qLtj1hv5/

Thanks to @Taar for help debugging this weird one.

I still see this as a major issue in IE that will have to be addressed.

(edit: these behaviors were documented with Windows 7, IE 11)

[marcysutton]

This is a "fix" that has probably caused more problems than it helped. I'll look into the IE issues above a little more.

[marcysutton]

Ok, I found out a few things after looking at the code in IE11. To address your bullet points:

• Changing ngAria to use keydown internally instead of keypress fixes the issue of events not firing on DIV/LI. I'll submit a PR.
• Sounds like if everything was wrapped in a form it worked fine, a.k.a. a non-issue. It still works in a form with keydown.
• To fix the button focus issue, add type="button" and it stops happening. I don't think ngAria can do anything about this without browser hacks, as IE is sending focus to the submit button (the default type in a form). So just add type="button", and you'll be all good.

Hope that helps.

[andrewaustin]

@marcysutton @kkoskelin I just tested on IE11 by adding type="button" to the original fiddle's two buttons and it fixes the original issue without changing the event from keypress to keydown. See http://jsfiddle.net/0Lsjvufn/

This seems to be an IE bug. Changing type to "submit" or a junk value like "abc" causes the bug to reappear.

I'm not sure changing the event to keydown is the right way to go because it may fire multiple types per keypress (if I understand the specs right).

Would it be feasible for ngAria to add type="button" if the type attribute is not set on <button> elements?

[marcysutton]

Sweet, that is good news! I'll leave the internal event binding as-is.

I personally do not think ngAria should be in the business of adding types to buttons, though. It's too hard to predict the right time for every situation.