-
-
Notifications
You must be signed in to change notification settings - Fork 625
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
Block level links not triggered with 'automatically set system focus to focussable elements' off #8528
Comments
This comment has been minimized.
This comment has been minimized.
Hi, The problem occurs when using the tab key to navigate between the three example links/boxes in the above Codepen, and then using the Enter key to trigger. If I exit NVDA, I'm able to tab/enter on all three boxes. I'm able to tab/enter on all three boxes in Chrome and IE when NVDA is running. |
This comment has been minimized.
This comment has been minimized.
Hi, thanks for the reply, I'm still experiencing this issue, using NVDA 2019.1.1 and Firefox 72.0.1. I have created a new demo page at: https://cdpn.io/DemoBrand/debug/QWwVZPq/xnMabZJGPpdr The three links on the demo page should open Google, NV Access and Github in new tabs. When using the enter key to trigger the links, only the third link works for me in Firefox when NVDA is running. When NVDA is not running all three links work correctly. As per the logs in my initial post, I suspect focus is being shifted to the inner block level elements when NVDA is running, so the links are no longer selected. |
@Adriani90 Hi, I've just updated the demo page for this issue: https://nvda-firefox-block-level-links-8528.netlify.app/ - I am still having this problem with NVDA 2019.1.1 and Firefox 75.0 |
This comment has been minimized.
This comment has been minimized.
@feerrenrut thanks for the reply. I tried using a different computer and also wasn't able to replicate the issue. After enabling logging I noticed the following line in Firefox: As the other issue is still open, would you recommend I close this issue? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
@feerrenrut thanks for the reply, hopefully it's not a common issue, however I was able to replicate the issue in Chrome and IE11 on a couple of different machines when browse mode was enabled. I have 'Enable browse mode on page load' and 'Automatic focus mode on focus changes' enabled and 'Automatic focus mode for caret movement' disabled in settings. Here's the steps and key presses I used:
Let me know if you need any further info. |
This comment has been minimized.
This comment has been minimized.
No, it isn't. It's a known bug when "Automatically set system focus to focusable elements" is disabled. See #9511 (comment), #10884.
I confirmed that the browse mode cursor always follows tab, even with this setting disabled. However, for some reason, when the setting is disabled, pressing enter doesn't work in this case. I don't know why. |
Yep, can confirm with the example page
I think this issue contains the clearest explanation of the problem, I'll reopen it. Note issue #9886 also looks related. |
I saw this issue not only for these links but also i.e. for buttons in some cases. It's occuring only when automatically set focus to focusable elements is disabled. For some reason NVDA seems to have problems in syncing the virtual cursor and the system focus. If the automatic set focus is disabled, when pressing enter or space NVDA should draw the system focus to the element on which the action has been performed in order for this to work. Maybe it is not trivial to gain the location properties of these links and that's why the action is not performed. Strange enough, with many other links it works properly but not everytime. To be honnest, I think the solution merged for the problems described in #9511 is not the best one for the long term but as far as I know there is not a better one sofar. |
This comment has been minimized.
This comment has been minimized.
I have updated the description of this issue, can someone else confirm that they can reproduce it with the steps mentioned (to ensure they are clear) thanks. |
I can reproduce it with the steps in the description. The steps can be also much more simpler.
Using NVDA 2020.1, Firefox 76 or Chrome 81. |
Edit:
Description has been updated with information from comments:
Steps to reproduce:
Using the example page at: https://nvda-firefox-block-level-links-8528.netlify.app/.
In browse mode,
tab
to each of the example links and press 'Enter' key to activate. With 'automatically set system focus to focussable elements' set it to off some don't activate.Settings:
NVDA+ 8
to turn toggle 'automatically set system focus to focussable elements'. Set it to off.Steps:
shift+tab
to land on the address barF6
to get back to the document, but we can be confident focus is not on a link.numpad+8
to hear "heading level 1 Example block level links"NVDA+space
to once or twice to confirm browse mode is enabled.Tab
to any of the three links and press enter, new page does not opennumpad+8
to hear the link "visited link heading level 3 Example 1"Actual behavior:
Firefox
With 'automatically set system focus to focussable elements' off (
NVDA+ 8
)The first and second example links are not triggered by pressing
Enter
.Chrome
With 'automatically set system focus to focussable elements' off (
NVDA+ 8
)The first and second example links are not triggered by pressing
Enter
.Expected behavior:
Enter should activate the link.
System configuration:
NVDA Installed/portable/running from source:
Installed
NVDA version:
2018.1.1
Windows version:
10.0.15063 Build 15063
Name and version of other software in use when reproducing the issue:
Firefox 61.0.1
Does the issue still occur after restarting your PC?
Yes
Have you tried any other versions of NVDA?
No
Other notes:
Looking at the NVDA logs, I can see these differences:
--IE11---
name: u'A third level heading\r\nSome sub text'
role: ROLE_LINK
states: STATE_FOCUSABLE, STATE_LINKED, STATE_FOCUSED
isFocusable: True
hasFocus: True
--FIREFOX---
name: u'A third level heading'
role: ROLE_HEADING
states:
isFocusable: False
hasFocus: False
The text was updated successfully, but these errors were encountered: