nvda
nvda copied to clipboard
nvaccess
Braille: show selection in edit controls and documents when tethered to review
Link to issue number:
fixes #15994
Summary of the issue:
When braille is tethered to review selection is not shown in edit controls and documents.
Description of user facing changes
Selection is shown when "Show selection" setting is enabled.
Description of development approach
- refactored
ReviewTextInfoRegion._getSelectionfunction - added
ReviewTextInfoRegion.updatefunction - modified
ReviewTextInfoRegion._routeToTextInfoso that when "move system caret when routing review cursor" is not "always", and review position is within reading unit which contains some selected text, second press of routing button on same cell performs activation - added if statement to
BrailleHandler.handleReviewMovefunction to capture gesture when region is instance ofReviewTextInfoRegionclass, and "Show selection" is enabled.
Testing strategy:
Quite limited testing for now.
Known issues with pull request:
When there are more than one line selected text, switching between applications causes variation which line (first or last)/its end part is shown from selected text. I do not know why this happens.
Code Review Checklist:
- [x] Documentation:
- Change log entry
- User Documentation
- Developer / Technical Documentation
- Context sensitive help for GUI changes
- [x] Testing:
- Unit tests
- System (end to end) tests
- Manual testing
- [x] UX of all users considered:
- Speech
- Braille
- Low Vision
- Different web browsers
- Localization in other languages / culture than English
- [x] API is compatible with existing add-ons.
- [x] Security precautions taken.
Could you @irrah68 and @jykke67 test this https://ci.appveyor.com/api/buildjobs/99cffsu59b9fncwv/artifacts/output%2Fnvda_snapshot_pr16038-30637%2C09359924.exe?
@seanbudd,
Referring to "needs product decision" label: are you consider alternative implementation, or are there such problems with this implementation which need more considerations?
I will await the product decision first. I did have a quick look though and honestly, it looks overly complex to me. If I understand it correctly, you want the review cursor to show the normal caret's selection, is that correct? I think for NV Access to take a proper decision, we need a rationale along with some use cases and scenarios to continue.
Currently if braille is tethered to review selection is not shown except maybe when switching from focus mode to browse mode but in general selection is not shown. This is not logical because show selection setting is available although it does not work.
When braille is tethered to review users can review edit controls and documents without affecting caret, and if they want they can route caret to their review position. But selection is not shown. To get to know is there selection (and what it is) they need extra steps.
Purpose of thiss pull request is to show selection changes in braille without extra steps when braille is tethered to review, and make it possible to review whole control/document so that users can detect where selection starts and where it ends but users are not restricted to review with in selection but they can review outside of it too.
I do not say at all that this pull request is good solution to this problem but wit this users have an additional possibility to utilize their braille displays.
Could you please describe how you select the text? Is this the seleciton done via nvda+f9 and nvda+f10? If yes, I think this needs to show up in braille indeed.
With shift+commands like arrows, home, end control-home-control end. But it seems (may) also to work with f9 and then f10. After f10 pressed selection seems to be shown with quick test.
At present it is impossible to check what text is selected for speech users when they're using review cursor. Is there a particular reason why it should be possible in Braille, but not in speech?
Yes it should be available in speech as well. But is it reason to block implementation for braille that there is no implementation (or maybe no plans) for speech.
I think support for speech can be implemented later although it would ofcourse be ideal to have both at the same time. There are already lots of situations where speech and braille are not having the same information output. In my opinion it is still better to have a feature implemented partially rather than not having it at all. @burmancomp would this mean huge effor to include reporting of selected text with review cursor in the nvda+shift+s command? As of now, when I select text with nvda+f9 and nvda+f10, and then press nvda+shift+s, the reporting is "no selection".
@Adriani90 wrote:
As of now, when I select text with nvda+f9 and nvda+f10, and then press nvda+shift+s, the reporting is "no selection".
Could you be more specific (steps, application, etc.)? Here in Chrome, when selecting with NVDA+F9/NVDA+F10, I can read the selection with NVDA+shift+upArrow (desktop layout)
I tried to select for example an element in Outlook emails list with nvda+f9 and nvda+f10 and then reporting selection was not working. However, in that case NVDA said "text could not be selected" but still I could copy the selection to clipboard by pressing nvda+f10 twice. Is this a bug in the speech module?
@lukaszgo1 in which case are you not able to retrieve selection information when selecting with review cursor while using speech? Is this the same use case like me? I supose Outlook email list is not an editable control or document so this might be the cause. In the virtual document or edit fields it seems to work as expected and I have the same experience like @CyrilleB79.
I tried to select for example an element in Outlook emails list with nvda+f9 and nvda+f10 and then reporting selection was not working. However, in that case NVDA said "text could not be selected" but still I could copy the selection to clipboard by pressing nvda+f10 twice. Is this a bug in the speech module?
No, this is expected - you are not able to select text outside of editable content / browse mode.
in which case are you not able to retrieve selection information when selecting with review cursor while using speech? Is this the same use case like me? I supose Outlook email list is not an editable control or document so this might be the cause.
That is not what this PR is about. When using NVDA+Shift+ up arrow you are retrieving selection from the focused object. What this Pr implements is an ability to show the selected text (regardless if it was selected from a caret or by using NVDA's selection commands) when moving with review cursor and using a Braille display. What I flagged as a concern is the fact that the same cannot be done with speech.
No, this is expected - you are not able to select text outside of editable content / browse mode.
Ok, but why can I copy the text to the clipboard though after I pressed nvda+f9, nvda+right arrow a couple of times, then nvda+f10 and then nvda+f10 twice?
What I flagged as a concern is the fact that the same cannot be done with speech.
Hmm maybe I misunderstood the exact way how this feature works. My understanding is that you cannot navigate the selected text in braille after merging this, but you can just read the selected text on the braille display. Right? If this is the case, then this is what nvda+shift+s or nvda+shift+up arrow does as well. It just reads out the text you selected. Pressing the command twice even spells the text you selected.
Actually why is this setting optional at all in braille? The selected text should always be shown, there should not be an option whether to show it or not. Is there any drawback from an user point of view between showing selection or not showing selection? In other screen readers this setting cannot be turned on or off. Moreover, in speech we don't have this optional setting and that is actually ok.
What I flagged as a concern is the fact that the same cannot be done with speech.
Hmm maybe I misunderstood the exact way how this feature works. My understanding is that you cannot navigate the selected text in braille after merging this, but you can just read the selected text on the braille display.
You should be able to navigate (review) both within selection and outside of it. You can use braille next/previous line, braille scroll forward/scroll back, and also some review commands (next/previous line/review bottom/top/review start/end of line. Selection changes should also be immediately updated to braille display, for example if you select character with shift+right arrow.
Actually why is this setting optional at all in braille?
Because reading may be more difficult when dots 7 and 8 are present (too many dots under your finger at same time).
@burmancomp thank you for the details. One question though, what happens when routing the cursor to a selected letter or sign with a cursor routing key? In other screen readers you can navigate the selected text with braille scroll keys, but as soon as you route the cursor, the selection is gone.
You write:
You should be able to navigate (review) both within selection and outside of it.
In this case I understand @lukaszgo1 that we cannot navigate with speech inside and outside the selected text. But this feature does not exist in other screen readers like Jaws or Narator as well. in my opinion at least this should not block this PR from being merged.
@burmancomp thank you for the details. One question though, what happens when routing the cursor to a selected letter or sign with a cursor routing key? In other screen readers you can navigate the selected text with braille scroll keys, but as soon as you route the cursor, the selection is gone.
I have not tested this except when "Move system caret when routing review cursor" is set to "always". Then cursor should move and selection disappear. I suppose that when cursor is not moved when pressing routing button, review position moves but when within selection this is not detected in braille because cursor is not shown (selection has priority over cursor).
@michaelDCurran and @seanbudd, Because user can move caret with single press when braille is tethered to review, why selection should not be shown to user as it is shown when braille is tethered to focus? Because with review cursor user can review whole edit control and document, and he/she can move caret with routing buttons to any location (although there seems to be limitation with browse mode but it seems to be also without this pull request), why should not he/she detect selection - no matter where or how large it is?
@burmancomp - can you please explain more, perhaps give examples in the form of user stories. i.e. what is a user trying to do, how and why
@burmancomp - can you please explain more, perhaps give examples in the form of user stories. i.e. what is a user trying to do, how and why
User wants to tether braille to review because he/she wants to review text without affecting caret position. He/she can move caret to review position with routing button when needed so he/she can edit whole text.
But working with text selection is not so simple. When user selects text, selection is not shown in braille line when braille is tethered to review, and it is difficult to get to know text what is around of selection (does selection contain all text user wants).
@burmancomp, to be more explicit, maybe you can describe one or two real-life situation where the user needs to know where the selection is while reviewing the text.
User should have possibility to check that he/she has selected what he/she wanted to select. It may help when he/she can check what is outside of selection.
I think jaws behavior in edit controls (depends on settings) may be quite similar which this pull request is suggesting when braille is tethered to review and "move system caret when routing review cursor" is "always".
This is also useful when selecting multiple regions of text or cells which are not next to each other like in MS Word or MS Excel.
I think jaws behavior in edit controls (depends on settings) may be quite similar which this pull request is suggesting when braille is tethered to review and "move system caret when routing review cursor" is "always".
Yes it is. I just tested with JAWS and Wordpad. I selected two words, read text with my Braille display, line by line, and the selected text, these two words, was shown as higlighted.