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
Disable "automatically set focus to focusable elements" by default #11190
Conversation
I've been using fast browse mode on my system for a while since #11130 was merged, but leaving as a draft until I know it's stable enough/there are no known major issues. Cc @jcsteh, @LeonarddeR, @mltony, @michaelDCurran. |
At least from an user perspective I can tell that it's working very good now, so it could be enabled by default. This needs to be documented properly in the changes.t2t, in the userguide and maybe also in the developers guide (i.e. shift+tab will still report the element with system focus, switching to focus mode and pressing tab shows a different behavior than pressing tab in browse mode because system focus will move from its last position which is different from the virtual cursor, etc.). A good documentation is very crucial here because otherwise we will get many bug reports by accessibility testers regarding NVDA not scrolling the screen, pressing tab not doing what is expected to do etc. |
There's one major outstanding issue which I think needs to be fixed before
this is enabled by default. If you force focus mode with NVDA+space, focus
is not routed to the focusable object under the cursor. IMO, that's an
unacceptable regression for default behaviour. I started looking into this,
but it's not quite as trivial to fix as I originally thought.
|
PR no longer blocked, since #11206 was merged. |
I'd like this to have a longer run in alpha, I'll look to review / merge this after branching beta. |
Now that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Happy to merge this, one minor issue that I missed previously.
Co-authored-by: Reef Turner <feerrenrut@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @codeofdusk
@feerrenrut, @jcsteh, now that this has become the Default behavior, what should we do now with issues like #2039, #5251, #5831, #6282, #6678 or #8999? #2039 and #8999 describe similar behavior, however I let both open because both contain valuable Input. |
Since fast browse mode is now the default and users are warned that disabling it may have performance and stability implications, I see no need to fix these issues when fast browse mode is off. |
One of the main reasons for keeping this on for me was to use the mouse routing command to click on elements that could not be accessed otherwise. How will the new browse mode effect this? Should there be/is there a command to temporarily move focus, or is it a part of the move mouse to navigator object command? I turned the new option off since this is the recommended behavior, so will report any results. |
How about low vision users who need also the scrolling of the screen? Or does the screen scroll automatically though?
Von meinem iPhone gesendet
… Am 25.06.2020 um 22:33 schrieb Bill Dengler ***@***.***>:
Since fast browse mode is now the default and users are warned that disabling it may have performance and stability implications, I see no need to fix these issues when fast browse mode is off.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Having this enabled by default is quite problematic for people who have disabled "caret moves review cursor" as there is no reliable way to move navigator object to the position of the browse mode caret. Being able to move it there is critical as we can only route mouse to the navigator not to the caret. I've created #9622 some time ago and I believe that if it would be fixed this situation would dramatically improve. @feerrenrut I understand that we are in the features freeze and #9622 can be technically classified as a feature request / enhancement but without it the new behavior is quite problematic for some people as explained above. Would you accept a pr fixing it i.e moving navigator object to focus moves navigator to the position of the browse mode caret? |
@feerrenrut Have you seen this commend of mine? Could you please share your opinion? In the current state people who are more comfortable working with review cursor not following caret are forced to enable "set focus to focusable elements" to be able to work effectively on webpages requiring mouse/object navigation. |
@lukaszgo1 Could you please create a new issue to explain this issue fully? Or are you saying that #9622 already covers the situation? If so, please update #9622 to explain how this PR fits in.
I'm not really sure that I understand this. |
I hope #9622 after my recent edit clears things up |
since #9622 has been fixed, I think there is no other issue open on this. Given that the screen scrolls automatically and the focus is moved to the virtual cursor when swithicng to focus mode automatically or with nvda+space bar, I think it makes sense to close those issues dealing with focus jumping etc. I will proceed with that. |
Link to issue number:
None.
Summary of the issue:
Especially after #11130, it may be worth considering disabling "automatically set system focus to focusable elements" by default.
Description of how this pull request fixes the issue:
Testing performed:
Tested that toggling the checkbox works as intended, and that NVDA+8 still works.
Known issues with pull request:
None.
Change log entry:
=== Changes ===