-
Notifications
You must be signed in to change notification settings - Fork 10
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
JAWS resistant to forms mode with role=application #293
Comments
@jessegreenberg, no I don't. I will need to check how JAWS handles these key events. |
Yes, that could definitely be, I will start looking there. It would be good to also see if this is happening outside of the sim (in a JSFiddle). |
Here is a fiddle to observe behavior in a more vanilla context. |
Here is a JSFiddle to test: |
@jessegreenberg, I do not know how to make sense of the fiddle example. What do the numbers mean? |
Sorry, it isn't well documented, just something quick to see if this is happening outside the sim. First number is the key code, second number is a counter for events, just so we can still see the event if we happen to press the same key twice. By using this example with JAWS, we will see if this is a screen reader problem by seeing if any numbers change after pressing enter on the button. |
Indeed, this is not a problem for JAWS in that JSFiddle, something else is going on in the sim. |
Getting inconsistent results, sometimes JAWS works fine with enter to switch to forms mode in the sim. |
In the click listener, wrapping focus in a timeout makes the problem (mostly) go away, now JAWS switches to forms mode after pressing enter 95% of the time: // focus
setTimeout( function() {
accessibleDragNode.focus();
}, 100 ); |
While testing, I noticed that JAWS removes the differences between enter and spacebar that are typically implemented by the browser. Typically, button click event is fired on down from enter and up from spacebar. When JAWS is turned on, click is fired on down from both buttons. We are not doing anything with keyup and keydown behavior on the button (because AT are so inconsistent in how they handle these events. So that makes me even more confused about why spacebar behaves differently than enter in this case. |
I am going to commit this, just tried picking up the balloon and releasing with enter and combinations of enter/spacebar and it worked 50/50 times with JAWS enabled. JAWS treats enter and spacebar differently on forms elements (http://www.freedomscientific.com/Support/TechnicalSupport/Bulletin/1404), and my best guess is there is some implementation quirk that is causing performance to stutter when using enter (maybe the a11y tree isn't updating at the right time?) Considering this closed, we can reopen if the issue crops up again. |
Awesome investigation, @jessegreenberg! |
You can now pick up and release the balloon with both enter and spacebar. When the balloon is picked up with spacebar, JAWS switches to forms mode and you can move the balloon with the letter keys. When the balloon is picked up with enter, JAWS does NOT switch to forms mode (no audible beep, and letter keys move the virtual cursor).
@terracoda do you know why this might be happening?
The text was updated successfully, but these errors were encountered: