CODEWITHSUNDEEP
javascriptaccessibilitynvda
Shawn
Shawn

Reputation: 3

Web Development - Screen Reader Blocks Keyboard Events

We hired an accessibility company (Acme) to evaluate our web pages. Our page has a group of buttons that can be clicked only one at a time, and among their requests are:

  1. Prevent the Enter Key to click a button, instead, make Space Key do the click.
  2. Make the Right Arrow key do the same as Tab Key (move to the next button).

Nothing extraordinary there. Just use javascript to intercept the KeyDown event, determine which type is pressed (Enter. Space, Right-Arrow), and do the appropriate action. I got that working like a charm....Until I turned on the Screen Reader (NVDA) :-( Then everything fell apart. NVDA blocks and overrides all the KeyDown events for all the keys except the Tab. Anyone has idea on how to achieve what Acme is asking for with the Screen Reader turned on?

Upvotes: 1

Views: 2634

Answers (1)

QuentinC
QuentinC

Reputation: 14697

tl;dr:

Don't go against usual conventions, unless you have a very good reason.

Space and enter

Concerning space and enter, both will normally activate the currently focused control, whether a screen reader is running or not. For HTML controls such as buttons and other inputs, the keypress is converted into a click event. This is a general keyboard convention.

Unless you have a very very good reason, you shouldn't go against normal conventions, simply because that's what's expected by the user. If the user presses enter and nothing happens, he/she will more probably conclude that the site isn't working and quickly leave, instead of trying the spacebar or looking around if there isn't a note somewhere explaining this weird behavior.

Additionally, the user may be running another kind of assistive tool that simulates a keypress on enter based upon another event, for example winking eyes or blowing in a tube. Many assistive technologies behave like keyboards, even if they are not actually keyboards. In this case, preventing Enter from working normally will just prevent those people from using your site.

If you are afraid of users pressing Enter at an unexpected moment, this is your problem, not user's problem. If the form is incompletely or incorrectly filled, you should notify the user about it. If you want to avoid processing the same action twice, you should disable the button after it has been clicked on it or pressed enter after the first time, and again, show a clue to the user that something is processing in case it takes a while to complete.

Arrow keys

Several screen readers offer two different modes of behavior, depending on whether the content is operable or not.

When some screen readerd encounter non-operable content, it enters "browse mode" (aka. "document mode" or "scan mode") 'takes control' of the keyboard, offering shortcuts for "next heading", "next word", "jump to navigation" and so on. In this mode, your own keyboard and mouse event handlers will never be triggered.

This is the perfectly normal behavior of screen readers in browse mode and you shouldn't attempt to change it. Arrow keys allow to read the page like a document in a text processing program, for example.

Many keys behave differently when a screen reader is running in browse mode, because these keys are needed for navigation.

Conversely, when the screen reader is in forms mode (aka. focus mode or input mode), input events are not intercepted, and work as normal, arrow keys will behave as you specified in your script.

NVDA enters forms mode when an operable element (such as a button or a text input field) is in focus. In this mode, you can handle arrow key events. It is primarily the semantics of the element in focus which decides the mode of the screen reader.

There are particular keyboard operation idioms for complex UI widgets (such as menus or radio button groups), where it is the whole widget that gets focus with TAB, and then arrow keys are used to manipulate focus within that widget). You should aim to follow these idioms if possible.

But beware because if you nest your elements incorrectly - such as a list inside a button - the screen reader wont really know how to handle it, and this can make the page difficult to read and/or use.

For more information on browse vs. input mode of screen readers, you can make a search.

Upvotes: 3

Related Questions