Why Javascript IF keyCode === Enter key or Spacebar key does not work with NVDA screenreader?
Asked Answered
A

3

7

I am working on accessibility for client's site and am using JQuery/Javascript to detect if Enter or Spacebar keyboard keys were pressed, which was working great...

$(document).addEventListener('keydown', navKeyboardHandler);

navKeyboardHandler = function(e) {
    console.log('a keyboar key was pressed'); // This does work

    if (e.keyCode === 13 || e.keyCode === 32) { // Keyboard Enter OR Spacebar pressed
        console.log('enter or spacebar key pressed ! ! !'); // This does NOT work
    }
};

...until I turned on NVDA to test keyboard navigation with a screen reader! It just flat out ignores this statement. Once in a while, this will trigger. Like once out of 10 or 20 keyboard presses. It is not consistent as to when it chooses to trigger.

What in my IF statement needs to be modified for this to work? Any help will be greatly appreciated. I am testing this with Chrome & Firefox on Windows.

Appointee answered 10/9, 2018 at 16:27 Comment(0)
A
4

I reached out to people in the accessibility community through their slack channel: web-a11y.slack.com

and someone provided a decent solution:

It probably won't fire because NVDA intercepts the keys if you are in browse mode, which is normal. If you were to manually switch to focus mode (insert + space -- you'll hear a "typewriter" sound), the code should get passed through.

Appointee answered 10/9, 2018 at 19:16 Comment(2)
Is there a way to trigger the (insert+space) keyboard event via JavaScript?Ferd
Seems like you are not able to do that as it is outside of browser control. Some users may have this mode by default, and some not and end up just switching back/forth. Best way is to try to make things happen on the click event, as this work in both modes (depends what your end-goal is though).Appointee
O
3

Add role="application" in your widget html and try it, it is working for me.

Oystercatcher answered 22/4, 2019 at 11:29 Comment(2)
Not sure how this would help. Could you elaborate with more detail for your answer and do you have links/documentation for reference? Thank you.Appointee
I think he is referring to this thread github.com/nvaccess/nvda/issues/7898#issuecomment-529384975Pumpernickel
M
0

It's likely not the JavaScript. It's probably in the HTML. Certain roles and aria attributes will tell the screen reader whether to be in browse mode or focus mode (or applications mode).

For example, when the tablist and tab roles are used as part of the tab widget design pattern, using the tab key to move focus onto the first tab in the set causes a Windows screen reader to automatically switch into applications mode. From that point all the keyboard interaction is handled by the script.

More about screen reader interaction modes here

More info about NVDA browse mode vs focus mode in the NVDA User Guide

Depending what kind of widget you are building (if you were to provide more information and your HTML code, perhaps I could elaborate) you may need to add different role or aria attributes to tell the screen reader to automatically switch to the most appropriate mode. I recommend you carefully review the WAI-ARIA Design pattern for whatever kind of widget you're building.

This link has additional information on which widgets trigger focus mode http://accessibleculture.org/articles/2012/09/aria-widgets-and-focus-forms-mode-support/

Mastermind answered 11/9, 2018 at 14:12 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.