Remove 'Automatically set system focus to focusable elements'

[seanbudd]

Link to issue number:

Closes #16469
Closes #15463
Closes #15780

Summary of the issue:

The behaviour of "Automatically set system focus to focusable elements" is not reliable or well supported.
It is known to cause many bugs and unexpected behaviour in browse mode.
If it is to be reimplemented, clear user stories, well defined behaviour and a better implementation is required.

Description of user facing changes

The setting "Automatically set system focus to focusable elements" is removed from the settings panel and user guide.
The keyboard command to toggle it has been removed, freeing up nvda+8
The behaviour for NVDA now assumes the setting is off (the default).

Description of development approach

• Replaced config.conf["virtualBuffers"]["autoFocusFocusableElements"] with False and then simplified the logic.
• removed related code to the setting

Testing strategy:

Smoke testing of NVDA in browse mode

Known issues with pull request:

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.

@coderabbitai summary

[brunoprietog]

Why remove this option and simply hide it? This will ruin the experience of add-ons like Object Location Tones. It is tremendously useful for me to focus the elements automatically for better perception. Please, I ask you to reconsider this. It is a terrible step backwards in the experience.

[brunoprietog]

Also pointed it in #15463. @ABuffEr, @cary-rowen, @lukaszgo1 and @XLTechie also agree to keep the setting and remove the command.

Are you sure this setting has no positive side at all when checked?

As far as I know, some add-ons, such as UnSpoken, rely on this option because they use the gainFocus event.

I agree with to possibly move it to advanced settings, not with to remove it at all. I cannot point to specific cases, but I'm sure to have used it towaydays from time to time, in poorly designed websites, where the alternative would be to move and move and move manually the focus or the mouse pointer.

Some poorly designed web pages may require users to enable this option as a temporary solution. It may be the fault of the web developer, but having a temporary solution is far better than doing nothing.

Finally, this option is off by default.

Removing this setting would be terrible for me. I use the Object Location Tones add-on to hear a sound every time I move through focusable controls. This really helps me to know where an object is on the screen quickly, and helps me to be more efficient when scrolling through the interface. It also helps me get a picture in my head of the layout of the interface, just as I can do when I'm using a touch device like my mobile phone. Isn't it already enough that it's disabled by default? There are only drawbacks to this

The fact that Object Location tones requires this option is caused by the deficiency in NVDA's core. I';d say this should be fixed before removing this option.

It seems that users who need this, know that they need it. As such, wouldn't a happy medium right now, be to remove the keyboard shortcut to prevent accidental activation by users who don't understand the ramifications, or who were reaching for something else?

Often when I read about problems with this option, it's from users who didn't even realize they had it turned on.

Since removing it would cause problems for a vocal minority, limiting its potential accidental use strikes me as a better first step, while we await some better synchronized scrolling to be implemented.

I also support moving it to advanced, but dropping the script is an easy first action.

[seanbudd]

@brunoprietog - thanks for re-raising this feedback.
We intend to remove this functionality, but want to ensure impact to add-ons are minimal.

Removing this setting would be terrible for me. I use the Object Location Tones add-on to hear a sound every time I move through focusable controls. This really helps me to know where an object is on the screen quickly, and helps me to be more efficient when scrolling through the interface. It also helps me get a picture in my head of the layout of the interface, just as I can do when I'm using a touch device like my mobile phone. Isn't it already enough that it's disabled by default? There are only drawbacks to this
As far as I know, some add-ons, such as UnSpoken, rely on this option because they use the gainFocus event.
The fact that Object Location tones requires this option is caused by the deficiency in NVDA's core. I';d say this should be fixed before removing this option.

Can these add-ons use the Browse mode cursor like NVDA highlighter? Would adding an extension point or other API endpoint allow them to still be conscious of the browse mode focus.

[brunoprietog]

I'm really not sure, maybe @josephsl has something to contribute here?

Anyway, this feature is still tremendously useful for dealing with some complicated websites. I also use it frequently when developing and diagnosing accessibility issues. It's very useful to know if an element is focusable but not tabbable, i.e. has tabindex=“-1”.

What would be the downside of moving this to advanced settings? This is already disabled by default and the keyboard shortcut would also be accidents free.

[seanbudd]

What would be the downside of moving this to advanced settings? This is already disabled by default and the keyboard shortcut would also be accidents free.

To put it simply, the feature is unsupported, buggy and no longer maintainable. Advanced settings is intended for supported behaviour, even if experimental, but is not a graveyard for features.

[seanbudd]

cc @masonasons author of UnSpoken. Can you please read the context of #17598 (comment) and let us know how we can best continue support for this add-on

[cary-rowen]

cc @mltony
The Earcons and speech rules add-on already has the functionality of the unSpoken add-on, but I would still support adding an appropriate extension point for the previous use case.

[masonasons]

Hi!

As is currently the situation, yes having Automatically set system focus to focusable elements off using unspoken causes you to not hear where links and other page elements are using the earcons. I'm not entirely sure how extension points in NVDA work, I've not gotten around to figuring that out yet and have limited time, but so long as there would be a way to know when NVDA lands on a browse mode element like a link or such and where that is located on the screen, I imagine it would be possible for someone to implement that support into Unspoken.

[seanbudd]

@masonasons - I think post_browseModeMove should work for this

[masonasons]

Is hat documented anywhere? I'll have a look

[seanbudd]

@masonasons - it's not documented perfectly but it's mentioned in the developerGuide and has some associate comments in the source code

[brunoprietog]

cc @dbernaca

[ABuffEr]

Hi,
recently, I enabled this option to show a web page correctly scrolled/focused during a working call.
So, is there an alternative way to get the same result?

[XLTechie]

Personally, I am most concerned about @ABuffEr's use case. AFAIK, other use cases can be arrived at by other means, though may require some re-engineering like for Unspoken. But stuff like this is why I supported removing the script first--a staged decommissioning of such a long-standing, though annoying, feature, would allow greater impact assessment. Remove the script, then a release or two later, the GUI. Keep the "hidden" config option until the supporting code goes away in 2026.1's breaking release. That's my two pennies, anyway.