-
-
Notifications
You must be signed in to change notification settings - Fork 641
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
Focus on element in gridcell: Using arrow keys makes NVDA switch to browse mode #8395
Comments
I'm having the same issue. With NVDA off, using the keys to navigate between focus works as expected, but once NVDA is on, arrow keys work as browse mode. |
This works as expected only when activating focus mode manually with nvda key + spacebar. It seems that the automatic switch to focus mode is linked only to edit fields but not to tables or grids. This is because most users prefer to navigate on websites in browse mode and use table navigation keys instead of switching to focus mode in the table itself. This is prefered because NVDA provides many quick navigation keys which simplify alot the navigation on websites. These quicknavigation keys work only in browse mode. But in browse mode it is not possible to type text into an edit field so this was the only use case where automatic switch to fucus mode was intended for. |
in my opinion NVDA works as expected here and this behavior should be maintained. But if I am missunderstanding your issue please do not hesitate to correct me. |
some versions earlier automatic switch to focus mode was also working for embeded dialogs. But most users complained about that or felt that it lowers the navigation speed. So NVDA does not switch to focus mode in web dialogs automatically anymore. |
but every user can switch manually to focus mode whenever it is required. |
I'm in focus mode and I press tab and land in a grid cell. Here using arrow keys works fine, I stay in focus mode. You don't find this behaviour wrong? |
@Shepard you mean when you land on the button "add" NVDA switches to browse mode where it shouldn't? I can reproduce this only if I have enabled "automatically switch to focus mode" in NVDA settings under browse mode. If the checkboxes for automatic switch are disabled, NVDA stays in focus mode once it was set with nvda+space bar. Well, you ask me if it does make sense that automatic switch to focus mode is linked only to edit fields? In my opinion yes. I am an user of NVDA but I do not see a important reason why I should use focus mode for all form fields. A button can be activated in most cases in browse mode as well and even if NVDA switches to browse mode, the button can also be activated with enter key. For me as an user it does not make a big difference then. The difference is that in browse mode I can jump much faster backwards or forwards to other fields using the quick navigation keys. |
@Shepard you are using the same example like in the description. Right? |
I am closing this issue since the behavior in NVDA is as expected when turning on automatic focus mode for the system cursor. This is only linked to edit fields. You can work around this by Manually enabling focus mode with nvda + space bar on any region other than an edit field, this will keep NVDA in focus mode even when automatic focus mode is enabled. So manually enabling focus mode has higher priority over automatically enable focus mode setting. |
Actually the issue #11413 does show a better way of reproducing what you probably mean. In that issue I can reprotuce the unwanded switch to focus mode. Maybe the discussion can be continued there. |
I do propose to repoen this issue. This behavior is still replicating in NVDA 2024.1, e.g. with the links in the DataGrid example 2 and 3. Why the change? The ARIA Authoring Practices pattern for grids recommends that when a grid cell contains a focusable element, the focus is placed on that element when users navigate to the cell (with arrow keys). This interaction pattern requires screen readers to enter into, and stay in, application mode while navigating inside a grid (unless the cell contains an element with role="document" and focus is placed on a child of that element). Unfortunately, whenever NVDA hits a focusable child of a grid cell, (link/button/checkbox), it automatically switches back to browse mode. From there it's no easy task to switch back to focus mode without losing your location in the grid, maybe even having to tab to the grid again. While NVDA works really well with grids when you force key passthrough mode manually, (using NVDA key + space) many users do not know of this shortcut, and they shouldn't have to. Proposed change: |
I implemented a widget using the ARIA roles grid, row and gridcell. Inside of the gridcells I have
<button>
s where one of them has tabindex="0" and the others have tabindex="-1". I implemented keyboard navigation with arrow keys using a roving tabindex. Now when the focus lands on the button with tabindex="0" and I try to use the arrow keys while NVDA is on, it seems to have switched to browse mode because the arrow keys navigate between text lines and characters rather than going to another button in a different gridcell, as my code would do. This happens in Chrome and Firefox.I'm basically following the example on https://www.w3.org/TR/wai-aria-practices-1.1/examples/grid/LayoutGrids.html#ex2_label for which this is broken as well. I'm also using a grid in a different place but there the gridcells don't contain buttons but have the tabindex themselves. In this case it works fine, NVDA seems to stay in focus mode.
Steps to reproduce:
Expected behavior:
Focus should move to the "X" button. This works when NVDA is off.
Actual behavior:
NVDA reads the character "e". With each press of the right arrow key it reads another letter of "Recipient Name 1".
System configuration:
NVDA version: 2018.2
NVDA Installed or portable: Installed
Windows version:
Windows 10 Pro Version 1803 Build 17134.81
Name and version of other software in use when reproducing the issue:
Chrome version 67.0.3396.62 (64 bit)
Firefox Quantum 60.0.2 (32 bit)
Other questions:
Does the issue still occur after restarting your PC?
Yes.
The text was updated successfully, but these errors were encountered: