nvda
nvda copied to clipboard
nvaccess
Drag and drop on the web requires focus mode when HTML buttons are focused
Steps to reproduce:
Navigate to the following codepen https://codepen.io/WW3/pen/KKoENOW?editors=1010 Switch the view to debug/full-screen Open NVDA (I am running 2022.2.2 on win 10) Tab through the [HTML] buttons and press enter or space to trigger some expected action
Actual behavior:
pressing enter or space on [any] of the focused HTML buttons. doesn't trigger the [keyboard only] event handlers
Expected behavior:
pressing space or enter should evoke an attached keyboard handler that mutate some styles, HTML attributes, and posts same live messages.
FYI, the general issue is that tab to focus on an HTML button and a following space/enter key press doesn't trigger focus mode (NVDA rely on browse mode space/enter to send click events). But, and here is the specific issue, when composing a drag and drop component, the web platform provide specific handlers for pointing devices (mouse, touch, etc). To support NVDA keyboard users, an alternative mechanism is required - dedicated keyboard events. FYI, Jaws (2022) handle this correctly - tab to focus, space/enter press evoke the registered keyboard listeners
NVDA logs, crash dumps and other attachments:
Not relevant
System configuration
NVDA installed/portable/running from source:
Installed
NVDA version:
2022.2.2
Windows version:
10 64bit
Name and version of other software in use when reproducing the issue:
A chromium browser or any other browser
Other information about your system:
No
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
No
If NVDA add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Not relevant
Note that in NVDA the user can manually swap to focus mode with NVDA+space a 'click' sound is heard when this happens.
pressing enter or space on [any] of the focused HTML buttons. doesn't trigger the [keyboard only] event handlers
In browse mode, this is by design. The accessibility API exposes a default action for the objects exposed. Chrome exposes the "click" action. Browse mode is intended as a UX overlay to improve the consumption of documents for NVDA users. If you are developing an application requiring rich interactions (such as drag and drop), you may benefit from using role=application to automatically enable focus mode, which will then let NVDA pass through keypresses. Though if this approach is taken, be sure to take care to make the application easy to navigate.
We'll consider whether the described would be an appropriate UX shortcut for users.
We'll consider whether the described would be an appropriate UX shortcut for users.
I think that expecting NVDA users to swap the mode is not something I'd rely on, and appending this as part of the component accName is also very problematic. Also, using role application just to make it NVDA friendly, is something I'd really prefer to avoid. Again, unlike NVDA, Jaws and VO does it correctly, without role application. I tried to refactor the button's event type from key*, to click but it did not work for me. I suspect it somehow conflicted with the drag events. I also, rewritten the buttons with div[role=button][tabindex=0], but still, with NVDA users need to swap to focus mode... As James Teh remarks here, this is an NVDA decision that did not take into account scenarios like drag and drop.
Firstly I shall just summarize NVDA's current behaviour and list some obvious workarounds by the user and author.
On a web page, NVDA is by default in browse mode.
The user can use the arrow keys to move around the page, single letter quick navigation to jump to specific places, and can press enter/space on elements to interact with them. For simple elements such as links, buttons, checkboxes etc, interacting means to "activate" them. This technically means either performing the "default action" on the element via the accessibility API (which is most likely converted to click() by the Browser, or
we may resort to physically clicking ourselves.
For more complex elements such as radio buttons, comboboxes, interactive lists etc, interacting means switching to focus mode, so the user can then use standard keyboard controls to manipulate the element.
Using the tab key in browse mode also may automatically switch to focus mode for certain complex elements, or those inside containers such as toolbars.
The most important bit of info here for this issue is that "activating" a button in browse mode clicks it. This is so far by design.
To work around this issue,
- The user could manually switch to focus mode
- The html could be changed to place each of the buttons in a div with a role of toolbar
A comparison with Jaws is fair enough here, assuming that Jaws does not simply switch to forms mode when the user presses space or enter on the button. I am assuming that rather it ensures the button is focussed and passes through the key press to the browser. Comparison with VoiceOver is invalid here as VoiceOver has no concept of browse mode.
I would support the idea of changing NVDA to do the following when pressing enter or space on a button in browse mode:
- Check if the button is focusable, and if so focus the button.
- Wait until / ensure that the button is focused, and send the original key press through to the browser.
- If the button is not focusable, or the button does not receive focus, then NVDA must fall back to performing the "default action" or clicking.
There is a risk here that there may be some buttons in the wild that can be focused, but do not activate on keyboard input. I would think the chance is very low, but up to now we have not depended on this.
If we were confident with this approach, we could consider broadening it to any simple element that is focusable. But always best to start with a limited change.
