Create unassigned gesture to toggle UIA
Closed this issue · 4 comments
Is your feature request related to a problem? Please describe.
NVDA uses UIA by default in some places (particularly newer versions of Word) and has it available as an advanced option in other places (Excel, console, Edge / Chromium, etc).
Currently the user needs to go into NVDA's advanced settings in order to change the UIA setting for a given program if the default is not suitable for their use case. For instance, some features work better WITH UIA and some work better without UIA.
Describe the solution you'd like
An assignable gesture so users who prefer, are able to toggle the UIA settings for the current application. For instance, #13460 details an issue using track changes with UIA. A user may have UIA when writing their document, but turn it off when reviewing someone else's document with track changes if this is an issue for them.
Ideally, the gesture would be able to change between the options available for the current program. For instance in Word, there are four options (Default, only when necessary, when available, and always), but for Excel, the option is an on / off toggle. My thought for this is that the change would be made for the program which is currently active.
Describe alternatives you've considered
The user can currently do this via the advanced settings dialog, however this is inefficient for those who may need to do this regularly.
Having NVDA automatically switch to get "the best" information at any point would be complex and inefficient, as sometimes "the best" information may differ from one use case to another, and would also require constantly cross-checking against an extensive and regularly updated list of which features worked better with UIA vs without it, in each possible build of each program a user may be using.
Additional context
Hi,
These settings rely on cooperation from UIA handler thread, which is actually a global thing. As an alternative, we could perhaps split UIA settings into its own settings panel, thereby creating an unassigned gesture to quickly open this panel.
Thanks.
For now, the UIA settings are in advanced settings panel. Theoritically, only advanced users should change these values, or other users if instructed to do so by advanced users. And you can modify these values only if you have checked "I understand that changing these settings may cause NVDA to malfunction" checkbox.
The realty is probably that many users, even not advanced, change these settings, at least the Word one.
Keeping these settings in the advanced settings and adding an unassigned command would allow a user to modify these settings without checking the disclaimer checkbox.
If it is confirmed that users may need to change these settings on a regular basis, these settings should actually be put out of the advanced settings.
Having NVDA automatically switch to get "the best" information at any point would be complex and inefficient, as sometimes "the best" information may differ from one use case to another, and would also require constantly cross-checking against an extensive and regularly updated list of which features worked better with UIA vs without it, in each possible build of each program a user may be using.
If NVDA devs cannot investigate these use cases and implement suitable solutions for each of them, it will be the responsibility will be put on the end user to answer these questions and decide how to configure the option:
- Do I prefer quicker navigation in big documents (UIA) or do I need to work with track changes (legacy)?
- Is my Word / Windows version high enough to use quicker navigation in big documents (UIA) or not?
It seems to me that using best of both interface is what Jaws does though. But I acknowledge that NVDA may not benefit of the same work force as Jaws does. The question is: why does NVDA need such options whereas other screenreaders do not?
If it is possible (technically and from a work load point ov view), the best solution would be to let NVDA decide when and where it should take the information from UIA or from other interfaces (IAccessible, object model, etc.); this matter of interface does not need to be known by the user.
If it is confirmed that users may need to change these settings on a regular basis, these settings should actually be put out of the advanced settings.
I don't think so, these settings are really for advanced and actually still experimental purpose indeed. The whole UIA API is still not really practical completely, so I would rather invest time in assessing the technical potential for solutions here. Note that #16214 will very probably make NVDA much more independent of Microsoft's own improvements to UIA, so technically it will become much easier to solve the current UIA issues I would assume.
Having these UIA settings out of advanced settings will very probably violate the policy of feature flags. I don't think it would be a good idea.
By the way, enabling UIA via a keystroke accidentally could have really negative effects, in some cases, and it will be really difficult to investigate imediately why users have problems. UIA related behavior is not that easy to discover when people report problems.
If it is possible (technically and from a work load point ov view), the best solution would be to let NVDA decide when and where it should take the information from UIA or from other interfaces (IAccessible, object model, etc.); this matter of interface does not need to be known by the user.
My understanding is that it is possible, but I think the purpose of NVDA was to test UIA separately until is stable enough, and then change to UIA when suitable. However, the stable stage of UIA has never been reached, nor in Jaws. The whole API is not a bullet proof solution yet, at least this is my feeling.
In the end it is really a pitty that IAccessible2 was built in parallel to MSAA and its successor UIA, and people made a competition out of API development. Microsoft, IBM and other API vendors like Oracle should have rather put forces together to build an universal API.
Now there is even the AoM (accessibility object model) which was pushed by browser vendors as a new API for the web only, and is still being developed I think.
https://github.com/WICG/aom/blob/gh-pages/explainer.md
Given that so many applications now use different accessibility APIs, the only way to go is indeed to Specify conditions which tell NVDA when it is suitable to use which interface. Maybe AI will help in bridging the gap of the huge effort needed.
Closing due to the arguments Cyrille raised