nvaccess
Text from NVDA native dialogs should be placed in separate read-only fields for improved keyboard access
Reported by vtsaran on 2008-12-24 06:51 Currently, text in such dialogs as "Welcome to NVDA" can be read only by pressing INSERT+B. To improve keyboard access as well as allow users to review the text with standard navigation keys, it would be desirable to have that text inside a separate control such as read-only text box. In addition to being navigable, this control should also be placed in the tab order.
Comment 1 by vtsaran on 2008-12-24 06:54 Before I am told that the text can be reviewed with NVDA review commands, I wanted to point out that my suggestion is primarily targeted at helping beginners who installed NVDA for the first time.
Comment 2 by jteh on 2009-02-03 04:21 One issue with this idea is that if the text is placed in a read only edit field, it will not be read automatically when the dialog appears. This is intentional, as otherwise, we would read the entire license agreement in installers, etc., which is undesirable. (In fact, I fixed this bug recently.) Perhaps we could make an exception for this particular dialog, but it seems contrary to standard practice.
Now there have been some recent changes to the welcome dialog and ideas about new content (e.g. #7249, #7242), this could be considered if desired. I'm not a huge fan of it though.
@leonardder @jcsteh @feerrenrut Could you please clarify if we wish to isolate the scope of this ticket to the Welcome dialog alone, or should we open to extending it to cover other cases in NVDA's GUI where such a change may be desirable?
Aside from the About dialog (where it probably would be useful to be able to copy at least some of the text), the Welcome dialog is the only dialog where there are big chunks of info the user might want to digest piece by piece. I think the scope should remain limited to the Welcome dialog. Note that my concern from https://github.com/nvaccess/nvda/issues/258#issuecomment-155279518 still stands, however.
Actually I don'T think it is a good idea to add read only edit fields for the information. It would increase the number of tabs you need to press to cross the dialog elements. Is it not confortable enough to use the OCR for this? Otherwise there could be kind of window virtualization implemented in NVDA, for example the addon maintained by @josephsl could be integrated in NVDA. Then an user could press for example nvda+ctrl+w to viertualize the window. The advantage of this approach would be that the results do not depend on OCR quality.
Unless I'm totally missing the point on this issue:
First, OCR shouldn't be necessary to read any of the dialogs in NVDA. However, I do agree that native dialogs could be made more intuitive to interact with for new users. I certainly found this difficult when first using a screen reader / NVDA.
For myself this came from not realizing that I could use numpad+7, numpad+8, numpad+9 to read this text by sentence (in desktop keys mode). Given the text can be read in this way, I think this issue could be closed. I would prefer it be replaced with an new issue requesting an improvement to the user guide to explain this interaction. It would be good if there was a small set of well documented common interactions that allowed new users to get by in most situations.
Would it not be possible to make pressing nvda+b twice display the window content in a browseable window?
Using object review to read the text is sometimes not really intuitive, especially when you have only a laptop keyboard at hand and the NVDA key is not the capslock key.
cc: @XLTechie, @CyrilleB79, @cary-rowen
Using object review to read the text is sometimes not really intuitive, especially when you have only a laptop keyboard at hand and the NVDA key is not the capslock key.
I don't really understand this comment. Could you not temporarily change the keyboard layout and/or NVDA key?
I'm also aware that adding more and more interaction patterns just makes the product more complex over all. This is all stuff we have to maintain, and users somehow have to be aware of. Adding an interaction modality to NVDA's dialogs that is unavailable on other standard system dialogs seems like a bad move from a consistency point-of-view to me, if nothing else.
Would it not be possible to make pressing nvda+b twice display the window content in a browseable window?
Note that there is Virtual Revision add-on by @LeonarddeR which already perform this task, probably with a dedicated shortcut.
Using object review to read the text is sometimes not really intuitive, especially when you have only a laptop keyboard at hand and the NVDA key is not the capslock key.
- Flat object review is more intuitive than normal (hierarchical) object review. It does not seem to be very well known but would benefit from being.
- On a laptop keyboard, if not having caps lock defined as NVDA key make things more complicated, what is the use case not to configure it as NVDA key.
Note that there is Virtual Revision add-on by @LeonarddeR which already perform this task, probably with a dedicated shortcut.
That's too much honor for me. The Virtual Review add-on is maintained by @ruifontes.
@SaschaCowley, @CyrilleB79 e.g. on one of my machines the capslock key is unfortunately damaged, so I cannot use it at all. Other NVDA key combinations for object navigation and object review are quite unconfortable, because NVDA doesn't allow for locking the NVDA key. So there are two alternatives, and they are not only impacting NVDA native dialogs but would bring more benefit in a lot of use cases:
- Make pressing NVDA+b twice display the windows content in a browseable window, should not be that hard to achieve since other combinations such as nvda+f, nvda+k or nvda+alt+c do this already
- Add a way in NVDA to lock the NVDA key on first press, and unlock it on second press. This at least would make object review much easier.
Ofcourse I could emulate the capslock key to another key in NVDA input gestures, but then other problems occur like:
- NVDA doesn't report when it is turned on or off after it is emulated
- Emulated NVDA key cannot be used to exit the input help mode.
In fact, emulating a key is too much hussle for fixing such a problem. I think in this case the development efforts for the alternatives above are worth it, because both of them open up more intuitive user experience, also for beginners.
Well, the suggestions made could be interesting or not. But in any case, the justification for these possible new feature should not be a very specific situation of one person using a broken keyboard...
There might be one handed people out there, so there are definitely valid use cases.Von meinem iPhone gesendetAm 18.01.2025 um 21:20 schrieb Cyrille Bougot @.***>: Well, the suggestions made could be interesting or not. But in any case, the justification for these possible new feature should not be a very specific situation of one person using a broken keyboard...
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>
There might be one handed people out there, so there are definitely valid use cases.
are these cases not covered by Windows sticky keys? Last time I tried this feature, Windows managed NVDA key too... It's the reason I discontinued this add-on, that could be useful in case of a broken keyboard though (but I agree with Cyrille it's not a valid reason for a core feature).
@Adriani90 I'm seconding Windows sticky keys. Is there a reason this doesn't work for your use-case?
@SaschaCowley in principle that's a god alternative, but at least for my use case I don't want every modifier key to become sticky, and there is no way in Windows to say which keys should become sticky. So that's why in my view it still makes sense to have an optional setting for the NVDA key. This is already implemented in narator, and Jaws hase also a one handed mode for its Jaws key.
@Adriani90 that makes sense. Could you either create an issue for a native NVDA key lock, or link the existing issue if there is one?
@SaschaCowley in fact I came again across #7749 which is a more viable solution in my view. Making the NVDA key lockable might be worth it, but it introduces the risk that people forget it and they change settings accidentally.