How do I disable NVDA's arrow key navigation
Asked Answered
G

2

9

I have a collection of buttons inside a div, with some javascript to move focus between them in response to arrow key events.

When I test this with NVDA/Firefox/Windows it seems that NVDA overrides my arrow key handler and moves focus according to its own rules. This is a problem because my widget is highly customisable, dynamic, and responsive - so the rules for moving focus around are quite complex.

Neither Voiceover nor ChromeVox has this behaviour.

I noticed that adding role="gridcell" to each button seems to fix this, but I'd prefer not to do that because it means screenreaders won't treat my buttons as buttons. I also really don't want to change the html structure (e.g. wrapping each button in another element) unless it's absolutely necessary.

Is there a way (e.g. aria or proprietary attribute) to tell NVDA not to apply its own arrow key behaviour to the buttons?

Gastrostomy answered 4/1, 2017 at 21:2 Comment(0)
S
7

If all your buttons are in a container (span or div), you can add role=application to the container and that will force all keyboard events to go to your application instead of to assistive technology. Role=application should be used very sparingly, though.

<div role=application>
   <button>alpha</button><br>
   <button>beta</button><br>
   <button>gamma</button><br>
</div>
Supranational answered 7/1, 2017 at 15:55 Comment(1)
Thanks - I ended up doing something very similar by adding role="toolbar" to the container; it fixed my issue with unwanted NVDA arrow key interception. Semantically it's totally correct as my widget is "a container for grouping a set of controls, such as buttons, menubuttons, or checkboxes" so I'm pretty happy with that.Gastrostomy
S
8

Consider that by overriding a user's expected behavior, you run the risk of creating a completely unusable, or even inaccessible, interface.

I strongly recommend against trying to do this.

Regardless, any ARIA you add to try to override it can affect non-NVDA users. NVDA intercepts arrow keys, so JavaScript cannot act until NVDA has already reacted to the arrow keys.

Note that NVDA users can already navigate between buttons using b and Shift + b, so they do not need to rely on Tab.

Now, all that being said, you may find an existing pattern that is similar to what you are trying to achieve in the WAI-ARIA Authoring Practices.

If you can outline your objective and maybe show an example, it is possible I can identify some existing patterns or techniques that will allow you to achieve your goal without risking a broken experience.

Secretary answered 5/1, 2017 at 3:20 Comment(2)
Thanks for the response. I actually authored the widget originally according to the "toolbar" section from the ARIA authoring practices page you linked - w3c.github.io/aria-practices/#toolbar. But I realised I didn't apply role=toolbar to the container: adding that role seems to change NVDA’s behaviour to be more reasonable. The widget is basically a “grid of buttons” that allows symbols to be entered into an input area.Gastrostomy
Ah, yes, I have forgotten a role more than once.Secretary
S
7

If all your buttons are in a container (span or div), you can add role=application to the container and that will force all keyboard events to go to your application instead of to assistive technology. Role=application should be used very sparingly, though.

<div role=application>
   <button>alpha</button><br>
   <button>beta</button><br>
   <button>gamma</button><br>
</div>
Supranational answered 7/1, 2017 at 15:55 Comment(1)
Thanks - I ended up doing something very similar by adding role="toolbar" to the container; it fixed my issue with unwanted NVDA arrow key interception. Semantically it's totally correct as my widget is "a container for grouping a set of controls, such as buttons, menubuttons, or checkboxes" so I'm pretty happy with that.Gastrostomy

© 2022 - 2024 — McMap. All rights reserved.