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

Whatinput changes to mouse incorrectly when using NVDA #68

Closed
stevenbriscoeca opened this issue Aug 29, 2017 · 9 comments
Closed

Whatinput changes to mouse incorrectly when using NVDA #68

stevenbriscoeca opened this issue Aug 29, 2017 · 9 comments

Comments

@stevenbriscoeca
Copy link

stevenbriscoeca commented Aug 29, 2017

Hello,

When I am using NVDA, what-input incorrectly changes the what-input to mouse in a specific circumstance.

Steps to reproduce :
Notes : Use NVDA and firefox.

  1. https://codepen.io/anon/pen/VzVjVW?editors=1111
  2. Navigate with tab to the button.
  3. Press Enter
  4. You will see the box dissapear

You will see what-input go from keyboard to mouse. It should stay in keyboard.

Without NVDA, it stays to keyboard.

@ten1seven
Copy link
Owner

ten1seven commented Aug 29, 2017

Thanks for the thorough steps to reproduce! I know there are a few instances where screen readers trigger mouse events.

I'm curious what happens if you move focus to another element before hiding the button? Screen readers classically have issues when a focused element is removed from the DOM (and I think display: none will do the same thing). The official term is "freak out" because they don't know what happened to the thing they were focused on.

Screen reader "freak out" => When an element that has focus is destroyed #accessibility #html5 #javascript via @jared_w_smith

— Arley (@ArleyTriana) February 23, 2015

What if you changed .hide to this CSS so the button is only visually hidden but isn't removed from the DOM?

.hide {
  clip: rect(1px 1px 1px 1px); /* IE 6/7 */
  clip: rect(1px, 1px, 1px, 1px);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

@stevenbriscoeca
Copy link
Author

Thank you for the quick reply.

I tried the css it still changes to mouse.

I also tried focus on the input text before closing and it's the same result
https://codepen.io/anon/pen/VzVjVW?editors=1111

Do you think this could be fixed in what-input? My gut tells me this is browser related.

What do you think we should do?

@ten1seven
Copy link
Owner

It's possible that NVDA is firing a mouse down event when activating a control. I'll look into it but it probably won't be today. Hopefully, I'll be able to check it out tomorrow or Thursday.

@stevenbriscoeca
Copy link
Author

Okay sounds good. This is open source, so you can do it when ever you have some free time and if you want to! I really appreciate it :)

@stevenbriscoeca
Copy link
Author

Any update on this? :)

@ten1seven
Copy link
Owner

Unfortunately, I haven't had time to look into this yet, but I've kept the email in my inbox so it doesn't go far off my radar.

@ten1seven
Copy link
Owner

I looked into this and was able to reproduce this issue on the What Input demo page. You can reproduce it by tabbing around to get "keyboard" triggered, then make your way to the checkbox and use the spacebar to toggle the checked state. This will flip the input state to "mouse". After a bunch of experimentation, I found that only with the NVDA+Firefox combination no keyboard events are fired at all.

I created this codepen to test: https://codepen.io/ten1seven/pen/yzPYrb?editors=1010

  • Open the console
  • Navigate by keyboard to the checkbox with your keyboard
  • Use the spacebar to toggle the value of the checkbox

In other browsers, you should see the keyup/keydown events firing, but with NVDA+Firefox only mouse events fire, even down to the checkbox itself. I'm honestly not sure where to go from here. It might be worth filing an issue with NVDA.

@stevenbriscoeca
Copy link
Author

Alright, do you want me to file a bug https://github.com/nvaccess/nvda ?

I'll obviously give you credit for your codepen and whatnot

@ten1seven
Copy link
Owner

Sounds good if you're up for submitting the bug!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants