Feature request: Include Sentence Nav as part of NVDA

[andrew-l-d]

Tony Malykh's Sentence Nav add-on is a most valuable resource. Not only does it resolve #5805, but it allows reading by sentence in a wide variety of applications. I humbly suggest that the facility to read by sentence should be an integral component of a screen reader. I have checked with Tony and he is happy for me to make this suggestion. Andrew

[DrSooom]

Please use NVDA+ALT-ArrowUp/ArrowDown instead of just ALT+ArrowUp/ArrowDown because otherwise it negatively influences the behaviour of ALT+ArrowDown in some programs like in MuseScore as well as comboboxes in Mozilla Firefox.

Quote from my "gestures.ini":

[globalPlugins.sentenceNav.GlobalPlugin] previousSentence = kb:alt+nvda+uparrow None = kb:alt+downarrow, kb:alt+uparrow nextSentence = kb:alt+downarrow+nvda

[mltony]

This is Tony - the author of SentenceNav.

1. My main reason to use Alt+Up/Down arrow is to make this shortcut consistent with Jaws. We probably don't want to make Jaws to NVDA transition harder by defining too many new keyboard shortcuts to learn.
2. Alt+Up/Down arrows on the combo boxes should not be affected in any application. When either of these keystrokes is issued, I check for the currently focused element and if it happens to be a combo box, I issue gesture.send() to have this keystroke be processed by the operating system.
3. Some other applications might indeed be affected by Alt+Up/Down shortcut being Overridden. But the same can be said about Control+UpDown arrows. In fact the same can be said about any NVDA shortcut that doesn't involve NVDA key. In this case I can argue that a potential workaround is to have the user to customize the keystroke in the configuration to avoid the conflict.

[fernando-jose-silva]

Outlook 2016 uses alt + arrow below to open the options of what to do with attachments. For being such a common software would vote for creating a function so that the alt + arrow below ignore the phrases function in this list of attachments in outlook 2016. For novice users pressing alt + down arrow in the list of attachments and seeing that it is not open can be frustrating and can lead to the user thinking that it is due to an error in nvda. Remapping keys in nvda is also not very logical for beginners.

[DrSooom]

At the SightCity 2018 a contributor told me that the screenreader user should never change the hotkey allocations. After he noticed that I'm an advanced user, he said to me that I can do this because I know exactly what I'm doing. (I don't want to name the company here.)

@mltony: Please do the following twice – once with your add-on enabled and once without it:

1. Open the Windows Explorer and open C:\Users.
2. Change the view to the detail view.
3. Press the right arrow once and you should be in a protected pseudo text field.
4. Press ALT+ArrowUp to go one folder higher (to C:).

So, please forget JAWS and use the NVDA+ALT-combos because it really isn't necessary in every application to have the ability to read by sentences. Only Alt+ArrowKeys cause to many navigations issues for all NVDA users. CTRL+ArrowKeys and CTRL+ALT+ArrowKeys haven't such negative effects yet (NVDA 2018.1).

[LeonarddeR]

Note that it is very unlikely and even undesirable to add sentence navigation to NVDA for cases other than the review cursor. Therefore, if sentence navigation is added, it will only be added to the review cursor (in which case kb(laptop):NVDA+ALT+upArrow and downArrow make much sense) and browse mode.

@feerrenrut and @michaeldcurran, do you have thought about this?

[DrSooom]

Well, and the abbreviations has also to be translated into the different languages as well. There are hundreds in German and some of them are written differently in Austrian German (de-AT) like "zB" and "z.B." for "z. B.".

@Adriani90: See ÖNORM A 1080 (which seems to be completely stroked since May 1st, 2018) or this PDF file. Only the abbreviations ending with a dot are important here.

Sadly this PDF file isn't complete. The following are missing based on my quick look: Mo., Di., Mi., Do., Fr., Sa., So., Hr., Hrn., abzügl., bspw., bzgl., bzw., gem., Jhd., lit., o.ä., o. ä., od., o.g., o. g., u.U., u. U., u.a. (without the space), Z. and maybe even many more.

[Update: 01:40 CEST): Tsd., Mio., Mrd., tägl., wöchentl., monatl., jährl., inkl. and exkl.

[andrew-l-d]

Re Leonard's comment: Note that it is very unlikely and even undesirable to add sentence navigation to NVDA for cases other than the review cursor. The Sentence Nav add-on is not restricted to review cursor and, in my experience, it is its general availability that makes it so valuable. Re the key combination, the only case so far where I have had to use the bypass is when saving attachments in Outlook. Having installed the add-on, it was immediately obvious that there would be a keyboard clash. It may not be as obvious to some users if the feature was part of NVDA upon installation (especially those who do not read manuals [smile]). But before getting bogged down in which key combination to use, a decision needs to be made as to whether the feature should be included as a core component of NVDA. While it is my view that people should not have to use an add-on to read by such a fundamental unit, that is not my call. Andrew

[mltony]

Okay, I seem to be outgunned here, I can change the keystrokes to NVDA+Alt+Arrows.

1. Do you want me to change it in my github repo? This is really a one-line change, so anyone can do it - e.g. whoever is going to be merging the code into NVDA.
2. Do you want me to change Alt+Shift+Arrows to NVDA+Alt+Shift+Arrows for jump to next text paragraph as well? Or we are not talking about jump to text feature in this issue?
3. NVDA has a built-in Alt+Up and Alt=Down keystrokes for MS Word and Wordpad - someone would have to change that to NVDA+Alt+Arrows to be consistent.

For the record, I still disagree that this is right decision. I agree to make the change, but I still need to address all your points here.

1. @DrSooom, you cannot ask me to forget about Jaws. It's still a leader in this market and most of NVDA users come from Jaws, and I would think that NVDA ought to care how easy it is to switch. You can tell me that not creating keystroke conflicts is more important than that, and this is a judgement call, and I would respect your opinion.

2. @fernando-jose-silva, @DrSooom, A quick search revealed that Control+arrows is used as a shortcut in Outlook and IE, I can send you the links if you want. Control+Alt+arrows is known to be a shortcut in Intel display drivers and remote console. So I would disagree that only Alt+arrows causes keystroke conflicts. It seems that NVDA users have been living for years with these conflicts. It's just that Control+arros seems to be a universal shortcut among all screenreaders and blind people never had a chance to use the original Control+arros keystrokes in Outlook. I would still agree that breaking Alt+arrows functionality in existing apps might be inappropriate, but I just want to point out that there are existing keystroke conflicts too. And the question again becomes whether we want to be consistent with Jaws or strive not to introduce any new keystroke conflicts? You have answered this question above, and I respect your answers.

3. Having sentence navigation bound to Alt+arrows would be consistent in many ways. Besides being consistent with Jaws (which I understand you don't care so much about), it would be logically consistent with other NVDA shortcuts, such as Control+Up/Down for paragraph navigation. It would be easy to remember for new users that Control key means to navigate by paragraph and Alt means by sentence. Moreover, it would be consistent with current NVDA behavior in Microsoft Word and Wordpad - Alt+Up/Down arrows is already bound to sentence navigation commands there. But I hear you, you care more about not creating new keystroke conflicts.

4. (Probably no one would care about this one, but I'll still say it here for completeness sake) I already use NVDA+Alt+Arrows shortcuts in my other add-on IndentNav. Sure, I can change it there too to something even longer, but we are running out of possible shortcuts involving the arrow keys. Soon someone might have to use some monstruous NVDA+Control+Shift+Alt+arrows for some new feature because all the other shortcuts will be taken by then.

5. The ideal solution in my mind would be to have NVDA the ability to assign a keystroke selectively depending on the currently focused control - that is only assign Alt+arrows keystroke in those contexts where navigation by sentence makes sense, such as text editor controls and HTML controls inside browsers and other apps. But when I did my investigation, that was not possible due to NVDA API limitations - correct me if I'm wrong here. Back from when I wass working on SentenceNav I remember that I found a way to define Alt+arrows shortcut only for edit box and MS Word controls, but there was no way to define it for browse mode, at least in an add-on. If it is done within NVDA, it might be possible to add a new keystroke just to Browse Mode. I hope this way would not cause any conflicts, since Alt+Arrows is not used in these contexts, with the exception of combo box - which is already resolved in SentenceNav. Does anybody think this is a viable option? Someone would have to implement context dependent keystrokes in NVDA and I don't know how difficult that would be.

6. @leonardder, could you explain why it would be undesirable to have sentence navigation in system focus mode? I would argue that having sentence navigation in system focus mode is more important that in review mode. I don't know about you - everyone uses NVDA in their own way, but I only use review mode in the places where system cursor cannot go to, for example command line window. This is a place where I don't need sentence navigation whatsoever - typically in command line window nothing comes out formatted as sentences. The places where I do like sentence navigation are browsers and text editors. In browsers I would have to switch to review cursor to read sentence by sentence and then route system focus to review cursor to keep reading - just more hassle than reading by sentence right with system focus. So I'm afraid, restricting sentence navigation to review cursor might only make this feature more difficult to use. And by the way, Alt+arrows shortcuts work as sentence navigation in MS Word and Wordpad in system focus mode out of the box. So if you think that this behavior is undesirable, should you remove this feature first or modify it to work only in review cursor mode?

7. @DrSooom, Surely enough other languages can be added. But I would like to point out that even without the dictionary of abbreviations SentenceNav can detect the vast majority of sentences correctly. You cannot detect all of them correctly. For example, "The president of U.S.A. is Trump.". In this sentence there is no way we can figure out that the dot after U.S.A. doesn't end the sentence. So even in the best case SentenceNav will only be 99% accurate. Now adding new abbreviations for say German might actually bring down accuracy for English, since there is no way to determine what language the text is written in. For example, if there is abbreviation "York." in german - I don't actually speak German, so this is just an example, then the dot in this sentence "I travelled to New York." will not work as a sentence delimiter in English text. So I just want to point out another trade-off here. I would say that adding abbreviations in other languages is Ok as long as it doesn't hurt accuracy in English.

[mltony]

Oh, and I forgot the most important one.

8. Most likely any keystroke conflict can be resolved. I have already resolved the conflict of Alt+Down on a combo box in Sentence Nav. I wasn't aware of a conflict in Outlook, but it shouldn't take too long to detect this situation when the focus is in Outlook and make sure that the original action is triggered.

[Adriani90]

@mltony, I guess alt+arrow keys is still the best option for this. ctrl+alt+arrow keys can for example change the screen orientation in MS Excel or in other applications. NVDA+Alt+arrow keys is also used in indentnav. Right?

In my opinion, the best way would be to lock sentencenav in such a way that NVDA reads automatically by sentence when pressing up and down arrow key. That means, NVDA would not read one line but one sentence. The keystroke to lock sentencenav could be something like pressing ctrl, shift, ctrl in this order. To unlock it you could press shift, ctrl, shift. Another possibility would be to integrate textnavigation in the settings ring and let the user decide what type of navigation should be applied for the nex arrow key presses (i.e. paragraph, sentence, line).

In any case this add-on should be part of NVDA's core as soon as the key conflicts are solved.

[Adriani90]

Guys, let's turn the discussion in the right way. We can discuss about NVDA and Jaws on the mail list if needed. We want to find the best way to work productively with NVDA and a comparison with Jaws is not the what we want to end up with.

[DrSooom]

@mltony:

1. I agree that it isn't really possible to correctly detect if "U.S.A." stands in the middle or at the end of a sentence. Example: I'm living in the U.S.A. And U.S.A. stands for United States of America. Microsoft Word 2010 navigates (because of the NVDA feature) without your add-on via ALT+ArrowUP/ArrowDown from "I" directly to the next sentence after "America.". Your add-on navigates here (now in Firefox, browse mode) correctly between this two sentences. So without an AI this won't be fully fixable.
2. I would recommend to add the ability to choose the list of abbreviations by the end user via a combobox in the NVDA settings. Oh, no, wait. The translated list of abbreviations should be related to the current used TTS language. So it would be change automatically every time when the TTS changes its language (e.g. based on the lang-HTML-Attributes).
3. I forgot "zzgl." in German and "e.g." in English.
4. In my opinion whitelisting ALT+ArrowKeys for just a limited amount of software (which should be enabled and disabled by the user) is easier instead of fixing possible bugs with all the other software at the market. It's still too much.
5. Only because I'm not using you add-on on my NUC, I was able to understand, that there wasn't a new bug in MuseScore regarding to ALT+ArrowDown and ALT+ArrowUp (which ´both are very, very important here!), this issue was caused to 100 % by your add-on. So if you add-on in version 1.0 is implemented in NVDA at this state, I guess that it would be quiet hard to checkout which application is responsible for this issue – especially for those who aren't familiar with PCs. We should never forget this group of users.
6. Well, and then: Should a sentence also to be split after a colon like in this question here? Of course, in the end the user should have the option to enable or disable this.
7. I'm just using your add-on in Firefox and Thunderbird. It doesn't work in HTML-E-Mails in Microsoft Outlook 2010 (browse and focus mode).
8. NVDA+ALT+ArrowUP/ArrowDown based on your add-on will only move the Cursor in Microsoft Word 2010 between the sentences, but NVDA speaks nothing. But in browse mode in Firefox speech and braille output exists. Why is this different?
9. And is it possible to disable the braille output (braille message) in browse and focus mode in Firefox, Thunderbird & Co., because hearing the braille cells moving irritates me a lot? That would be nice too. Thanks.
10. And your add-on interrupts/stops SayAll, CTRL+ArrowUp/ArrowDown doesn't do this in browse mode in Firefox and Thunderbird.

@Adriani90: I see that including this feature into the settings ring could be useful for some users. But your recommendation about locking and unlocking with CTRL » Shift » CTRL is much too complex for non-advanced NVDA users – and inefficient as well because you have to press too many keys just for using a single function.

[mltony]

@DrSooom

1. I like your idea to only enable Alt+arrows in a white list of apps as long as this list can be configured by the user. I think this is a reasonable compromise that would satisfy everybody. I would be OK with black list too.

2. I admit that keystroke conflicts should be taken seriously. Unfortunately I haven't used MuseScore before and nobody brought it up to my attention until now, that there is a conflict in it. There are multiple ways to resolve this conflict, one of them being your white list idea, another being to only redefine Alt+arrows shortcuts in edit boxes and HTML controls - - as I mentioned that is not possible within add-on API, but it should be possible if implemented within NVDA itself.

3. I just checked - it works in my Outlook 2016 in both focus and browse mode. I'll need to find a computer with Outlook 2010 to see what's wrong. Are you using the latest version 1.1?

4. NVDA+Alt+arrows is currently not a shortcut in SentenceNav. Did you mean Alt+arrows?

5. Sentence navigation in Microsoft Word comes with NVDA out of the box and is bound to Alt+arrows. That is you don't need SentenceNav for this to work.

6. I'm not sure what did you mean about braille cells moving and Braille message. SentenceNav currently calls ui.message() to speak and to the best of my knowledge, this is a suggested way for an add-on to speak. If there is another function I should use rather than ui.message(), let me know. Same applies to say all - that must be how ui.message works.

@Adriani90,

1. I don't like the idea of switching between line navigation and sentence navigation modes with a keystroke, because it adds some internal state that user would have to keep in mind. Also it prevents muscle memory from forming. This reminds me of rotor function in VoiceOver for IOS, where swipe up or down might mean jump by character, word or heading. In the end you never know which one is active and you always have to check the rotor setting. But in their case using rotor is justified because there are only so many swipe gestures available. Also navigation by line using Up and Down arrow keys is a system function, not an NVDA one, so if we have to catch these keystrokes and resend them to the system only when the mode is set to line navigation, this might cause some unexpected bugs.

2. Yes, I am already using NVDA+Alt+arrows shortcuts in my other add-on IndentNav.

As for whether sentence navigation should be a part of NVDA core - you guys should decide. I am obviously biased, I missed this feature a lot when I switched to NVDA and it is extremely important to me. I find it especially useful when reading scientific papers or articles, where I need to repeat every sentence multiple times. In this case if I'm left with line navigation, my brain has to keep diverging some share of attention away from the topic of the article just to reconstruct the boundaries of the sentences.

[ehollig]

Two related issues, #5463 and #1873

[DrSooom]

@mltony:

1. As you could might remember I remapped the default hotkeys from ALT+ArrowKeys to NVDA+ALT+ArrowKeys. That's why your add-on in version 1.0 works differently in Microsoft Word 2010 – but not longer with version 1.1. (I updated it now.)
2. The issue with Microsoft Outlook and HTML-E-Mails was fixed by version 1.1.
3. Press NVDA+F12 for getting the current time. It is also shown for a few seconds on the braille display. And sadly it's exactly the same with your add-on in version 1.0 and 1.1 in browse mode in Firefox and Thunderbird as well as in (Windows) Notepad for sentences. In other words: Every sentence is shown with its first word at cell No. 1, even if the sentence beginning normally appears in the middle of the braille display. And after this 4 seconds (default Braille Message Timeout) the braille display will show the normal (browse mode) layout of the text. This behaviour doesn't exist with CTRL+ArrowUp/ArrowDown. Maybe there is an limitation for add-ons here. But I haven't the knowledge to claim this.

[LeonarddeR]

Alt+upArrow and alt+downArrow both are shortcuts used in applications for sentence navigation. Note that in these cases (e.g. MS Word), the application itself is responsible for the sentence navigation. The only reason why NVDA reads by sentence in MS Word is because Word moves the cursor and NVDA reflects that behaviour with speech.

Update: it turns out that my assumption was wrong, see also #8541 3288

[netblue44]

Where can I get this addon

On 19/07/2018 12:23 p. m., mltony wrote:

This is Tony - the author of SentenceNav.

1. My main reason to use Alt+Up/Down arrow is to make this shortcut consistent with Jaws. We probably don't want to make Jaws to NVDA transition harder by defining too many new keyboard shortcuts to learn.
2. Alt+Up/Down arrows on the combo boxes should not be affected in any application. When either of these keystrokes is issued, I check for the currently focused element and if it happens to be a combo box, I issue gesture.send() to have this keystroke be processed by the operating system.
3. Some other applications might indeed be affected by Alt+Up/Down shortcut being Overridden. But the same can be said about Control+UpDown arrows. In fact the same can be said about any NVDA shortcut that doesn't involve NVDA key. In this case I can argue that a potential workaround is to have the user to customize the keystroke in the configuration to avoid the conflict.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/8518#issuecomment-406370076, or mute the thread https://github.com/notifications/unsubscribe-auth/API6eah5XsLTbqfSggG90tDSOGrHYnwHks5uIM6EgaJpZM4VVy1H.

[mltony]

@leonardder:

1. That's not true. Microsoft Word doesn't provide Alt+Arrows keystrokes out of the box. Try searching the list of MS Word shortcuts and you won't find Alt+Arrows bound to anything. Nor does MS Word provide any other keystroke to navigate between sentences. Alt+Up and Down arrows is an NVDA shortcut, that currently only works in MS Word. I am actually not quite sure how it works, but my best guess is that MS Word keeps track of sentences in the document and NVDA retrieves this information via some API call to Word. But I bet someone else knows more how exactly this happens. Also you can verify that Alt+arrows don't work in Narrator in Microsoft Word.

2. Why do you think NVDA should not add read by sentence functionality with alt+arrows? If other developers have any arguments I am welcome to hear them.

3. We are not stuck. You can view SentenceNav as a working prototype of this functionality.

[LeonarddeR]

Wow, my apologies there. I really was quite sure that this was Word functionality, but #3288 turns out that this is NVDA specific indeed.

[DrSooom]

@mltony: Sadly I forgot to mention two more things regarding to date:

1. German abbreviations for months: Jan., Jän., Feb., Mär., Mrz., Apr., Mai., Jun., Jul., Aug., Sep., Sept., Okt., Nov. and Dez.
2. And of course the date format which is mostly used in German: d. mmmm yyyy or dd. mmmm yyyy. Currently your add-on in version 1.1 split a sentence within the mention date. So please try to implement a rule that "01. " to "09.", "1. " to "9. " and "10. " to "31. " won't be detected as the end of a sentence. And as the day is mentioned alone it also shouldn't split here. Example: Heute ist der 24. und morgen der 25. Juli 2018. (EN: Today is 24th and tomorrow July 25, 2018.)

[mltony]

@DrSooom:

1. I propose to separate adding fine-tuned support for German and other languatges into a separate issue to be worked on perhaps later, assuming if we agree on this one first.

2. Can a German sentence end with a number? Something like "Dieses Number ist 25." If this is a valid sentence, then we cannot claim that a dot right after a number is a sentence breaker. It might be still worth it to break the sentence here anyway, just because dates tend to appear way more often than sentences ending with numbers. In this case we should just add all the numerals 1-31 to German dictionary - that is when language-specific dictionaries are implemented - because probably it's a good idea not to introduce language-dependent code, especially when we can get around by language-dependent dictionary.

[DrSooom]

Yep, of course this could be happen, but the date appears more often. In the end I suggest a checkbox for this, so the user can enable/disable sentence splitting here. By default splitting here should be disabled.

[netblue44]

Yep and Jaws uses the same keystroke to do the same thing.

On 23/07/2018 01:15 p. m., Leonard de Ruijter wrote:

Wow, my apologies there. I really was quite sure that this was Word functionality, but #3288 https://github.com/nvaccess/nvda/issues/3288 turns out that this is NVDA specific indeed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/8518#issuecomment-407169835, or mute the thread https://github.com/notifications/unsubscribe-auth/API6eQ747lMs_ka7sqM2K_ayScTZODslks5uJiDJgaJpZM4VVy1H.

[LeonarddeR]

This issue has been abandoned for some time now. Honestly, the more I think about this, the more I believe that Sentence Nav should stay as an add-on.

[andrew-l-d]

I fundamentally disagree that one should have to get an addon to read by sentence. All other Windows-based screen readers I have used include this facility. As I mentioned previously, reading by sentence is (or should be) a basic reading mode. The discussion here became bogged down with debate about the best keystroke when the real issue is whether NVDA should provide people with the ability to read by sentence (incidentally, I changed to Windows-arrow keys). Can you give me one good reason why reading by sentence should not be provided, especially now that addons will cease to be available if their developers do not continue to revise them?

Andrew

[mltony]

@leonardder I'm not sure why did you reopen this discussion now, but a year ago you already called sentence navigation "undesirable" - see your own comment in this thread from on Jul 19, 2018. Has anything changed since then? And it would greatly help if you could provide some justification about your opinion - otherwise it sounds like a personal preference.

[Adriani90]

This feature is so often requested by users, honnestly I don't know why it is so complicated to implement it. There is already an addon which works. Why not taking its core function and implement it into the core? Obviously this feature is not an exception, it is a navigation mode that every screen reader user would expect to belong to the standard package. cc: @feerrenrut, @michaelDCurran

[josephsl]

Hi, part of it has to do with controls exposing such a feature (NVDA already supports sentence navigation in Microsoft Word because Word does expose this information). Another problem has to do with figuring out sentence demarcation in languages such as Chinese and others. Thanks.

[Adriani90]

But the addon works and we do not get negative feedback from users all over the world. All users that are using it do not have these problems. So why not making it part of advanced settings? So that beginners and other users can try it out and report further if there is a problem?

[josephsl]

Hi, just because users do not report problems should not be the only justification for including this into NVDA Core. Thanks.

[mltony]

@josephsl You are pointing out problems that have already been solved in SentenceNav. I think the question is whether we should incorporate SentenceNav into NVDA core.

part of it has to do with controls exposing such a feature I'm not sure I understood what you meant by this. It's true that most of the applications (except Microsoft Word) do not provide API to parse text into sentences. That's exactly why I created SentenceNav. Another problem has to do with figuring out sentence demarcation in languages such as Chinese and others. SentenceNav has been reported to work well with Chinese language. It should also work with Korean and Japanese. It is also reported to work well with many European languages. In general it should work well with all languages using Latin or Cyrillic as their writing system. I have no knowledge of other languages, such as Arabic or Indian languages, which don't use Latin script, so I don't know whether SentenceNav would work well with them, but it's going to be pretty easy to add support if there is a speaker of these languages available to explain the rules.

[Adriani90]

In my opinion it should if this is part of advanced settings. UIA for MS Word has been implemented as well although it has still lots of problems. Sentence nav is even more stable than UIA in MS Word and it is requested by many many users worldwide. I don’t see why to favorize an experimental setting over a feature which is already quite stable. And in fact, you could let the gesture unassigned and everyone could assign it for him- or herself in the input gesture dialog.

[josephsl]

Hi, @MichaelDCurran, any thoughts? At this point I’m somewhat convinced that it should be considered for NVDA Core. Thanks.

[josephsl]

Hi, I’m thinking it should not be a feature flag toggle – it should be available from everywhere with unassigned commands (or Alt+up/down arrows).

[DrSooom]

@josephsl and @Adriani90: Please see my comments here, here and here.

[mltony]

@DrSooom I fixed most of these issues long time ago. In particular:

1. The list of exceptional abbreviations is now language-dependent.
2. Sentences are now spoken using proper functions (such as speech.speakTextInfo() rather than ui.message())
3. SpeakAll functionality has been fixed - thanks to @CyrilleB79
4. I do believe that Alt+Down and Alt+Up are the right keystrokes for sentence navigation and I didn't change them despite some requests. I do have strong arguments to keep using these shortcuts. You can read my arguments here: https://github.com/nvaccess/nvda/issues/8518#issuecomment-406765476 But I would like to assure you that using these shortcuts will not break any existing functionality - e.g. Alt+Up/Down is used as a shortcut in some apps - and this functionality is still going to be working. There is some extra effort in this, but not much and I believe that keeping the keymap consistent and simple is worth that effort.
5. I believe SentenceNav now works correctly in MS Outlook - the bug has been fixed long time ago.

[Brian1Gaff]

I would agree especially since python 3 may back a number of add ons, one really should re evaluate core functions in this light or we are going backwards generally.

[LeonarddeR]

@leonardder I'm not sure why did you reopen this discussion now

I just stumbled upon it while doing triage.

but a year ago you already called sentence navigation "undesirable" - see your own comment in this thread from on Jul 19, 2018. Has anything changed since then? And it would greatly help if you could provide some justification about your opinion - otherwise it sounds like a personal preference.

First of all, my opinion that sentence nav shouldn't be in core in its current form is nothing personal against your add-on. In fact, I think it is a pretty nice add-on actually.

I assume you meant this comment.

I agree that I should have been more clear in justifying my opinion.

1. First and foremost, sentence navigation is something for which edit controls usually do not offer support. UIA and Word offer support for sentence navigation in their TextInfo implementations, but that only seems to be a bonus which is thankfully used by NVDA and JAWS to allow navigation by sentence. The fact that alt+up/alt+down arrow are used even made me assume that these short cuts were application specific, which they aren't. I've always been in strong favour of putting NVDA specific gestures behind the NVDA key, browse mode being the only exception to that.
2. If sentence navigation would be integrated on a broader scale, other than for Word and UIA, NVDA would have to calculate Sentence start and end positions manually. As @josephsl pointed out in https://github.com/nvaccess/nvda/issues/8518#issuecomment-538084574, sentence demarcation is different for some languages. Now, you pointed out that most if not all of these issues have been solved. However, if we introduce sentence nav as part of NVDA, the main responsibility to maintain it would go to NV Access. I'm not sure whether they are willing to take that responsibility, that's why @josephsl asked @michaelDCurran's opinion about it.

Just to summarize my opinion again, I think sentence nav would fit in core if:

1. Other than in browse mode, It would only apply to the review cursor as pointed out in https://github.com/nvaccess/nvda/issues/8518#issuecomment-406496438 .
2. it doesn't put an extra burden on translators (i.e. because they have to offer a list of abbreviations per language that are skipped when calculating sentence endings). Language specific rules are very difficult to maintain, #4273 being a perfect example.
3. It aims at offering a fast as possible approach for several textInfo implementations. This probably means that we'd need an implementation in textInfos.TextInfo, and another one in textInfos.offsets.OffsetsTextInfo.

[lukaszgo1]

@leonardder wrote:

1. Other than in browse mode, It would only apply to the review cursor as pointed out in #8518 (comment) .

I think that making it working only when review cursor is active would make this functionality mostly useless.

[mltony]

@leonardder

First and foremost, sentence navigation is something for which edit controls usually do not offer support.

The vast majority of computer programs are written for sighted people. Therefore they don't contain features/APIs that blind people might consider useful. Sighted people parse text into sentences with their eyes, they don't need an API for that. Therefore it's up to us if we want to improve our experience with these programs. I don't see why you would want to constraint NVDA to only use provided APIs, especially since you yourself gave an example of browse mode - something that blind people developed for themselves to interact with web browsers. Previous discussion in this thread shows that people want to have sentence navigation, and it sounds really weird to me when you say that NVDA is not going to provide it because programs offer no ready API for it and we don't want to implement it ourselves because of that artificial constraint. Especially since other desktop screenreaders (Jaws, VoiceOver) don't create this artificial constraint for themselves, this would put NVDA at a disadvantage.

UIA and Word offer support for sentence navigation in their TextInfo implementations, but that only seems to be a bonus which is thankfully used by NVDA and JAWS to allow navigation by sentence.

Jaws supports sentence navigation everywhere, so that's not a bonus for them. By the way, VoiceOver for mac supports sentence navigation everywhere too. So that leaves NVDA as the only major desktop screenreader that doesn't support sentence navigation yet.

The fact that alt+up/alt+down arrow are used even made me assume that these short cuts were application specific, which they aren't. I've always been in strong favour of putting NVDA specific gestures behind the NVDA key, browse mode being the only exception to that.

I don't want to get bogged down in shortcuts discussion again, but I would like to mention that Alt+Up/Down shortcuts for MS Word were added in NVDA many years ago and not by me. Also they are consistent with sentence navigation shortcuts in Jaws. I don't know why you assumed that these shortcuts are application specific, and they are not the only ones. Other examples include Control+Arrows, Control+alt+arrows, Control and shift keys alone, there's probably some more. So browse mode is definitely not the only exception to that.

2. If sentence navigation would be integrated on a broader scale, other than for Word and UIA, NVDA would have to calculate Sentence start and end positions manually. As @josephsl pointed out in #8518 (comment), sentence demarcation is different for some languages. Now, you pointed out that most if not all of these issues have been solved. However, if we introduce sentence nav as part of NVDA, the main responsibility to maintain it would go to NV Access. I'm not sure whether they are willing to take that responsibility, that's why @josephsl asked @michaelDCurran's opinion about it.

I would welcome Michael's opinion on this. Recently there were discussions on NVDA mailing list that NVDA is going to take over some add-ons, such as Screen curtain and NVDA remote. So apparently NVDA doesn't mind maintaining some add-ons. The question that I would like to ask here is whether sentence navigation is: a. more useful than for example screen curtain? b. requires more maintenance than screen curtain? I think these are the right questions to ask. And yes, I am quite aware of the maintenance cost. And I am here in that awkward position where I suggest NVDA to take over SentenceNav and maintain it. Yet I still believe it might be beneficial for NVDA users to have sentence navigation as a part of NVDA core, primarily since only 10% of NVDA users know what is an add-on and how to install one, and that's probably an overly optimistic statement.

Just to summarize my opinion again, I think sentence nav would fit in core if:

1. Other than in browse mode, It would only apply to the review cursor as pointed out in #8518

It would help if you could provide any arguments as to why you think sentence navigation in system focus mode should not be allowed. You are using this repeatedly as one of your main arguments, yet many people here on this thread including myself strongly disagree with it. Again, Alt+Down and Alt+Up arrows work in System focus mode in Jaws, they work in system focus mode in NVDA in MS Word, and even in VoiceOver for mac despite different shortcuts sentence navigation works in their version of system focus mode. And SentenceNav extends this functionality to all other applications. So restricting to review cursor while technically probably possible, makes no sense to me, since it ruins all the consistency between the shortcuts. Why navigation by paragraph happens in system focus mode, navigation by sentence happens in review cursor mode and navigation by line and word happens in system focus mode again? Except for MS Word, where sentence navigation already happens in system focus mode. And except browse mode too.

2. it doesn't put an extra burden on translators (i.e. because they have to offer a list of abbreviations per language that are skipped when calculating sentence endings).

Oh really? adding one more string to translate into language is a burden? Now I have to admit, that getting the list of all the exceptional abbreviations for a language might be more complicated rather than translating yet another string. But still I think it's a gross exageration to call it a burden. Moreover, it's optional. SentenceNav is going to work very well even without proper list of exceptional abbreviations for the language.

Language specific rules are very difficult to maintain

Nope, they are not. At least in this case. At this point I really have a single regular expression that catches sentence boundaries in all languages, including European languages and CJK. And again it's a matter of finding a speaker of a new language to make sure that my regexp can be adopted to the rules of that language.

3. It aims at offering a fast as possible approach for several textInfo implementations. This probably means that we'd need an implementation in textInfos.TextInfo, and another one in textInfos.offsets.OffsetsTextInfo.

Currently SentenceNav has only a single implementation that works with any TextInfo object. If you are trying to say that SentenceNav is not fast enough - please say it explicitly. If you are not trying to say that, then there is no need to rewrite SentenceNav logic to make it more optimized, and therefore there is no extra cost here.

[CyrilleB79]

If sentence navigation is integrated in core (what would be a good thing IMO), defects of the add-on still need to be corrected. E.g. I have just entered one : Alt+up arrow throws an error in Windows Explorer

Also all the configuration settings should be reduced.

[mltony]

@CyrilleB79 If we ever come to a positive conclusion here, then the right thing would be to implement sentence navigation keystrokes in the right places, e.g. browse mode, editable control, perhaps a few more. However, as long as SentenceNav is an add-on, this is impossible to do from within add-on API, or rather a great deal of hacking would be required. Therefore, Alt+Up/Down keystrokes are declared as global shortcuts, which is not right, but that's the best I can do while being constrained by add-on API.

Also all the configuration settings should be reduced.

Some people request more configuration options, others complain there's too much. These details can be sorted out later.

[CyrilleB79]

If we ever come to a positive conclusion here, then the right thing would be to implement sentence navigation keystrokes in the right places, e.g. browse mode, editable control, perhaps a few more.

OK, so all good for me.

However, as long as SentenceNav is an add-on, this is impossible to do from within add-on API, or rather a great deal of hacking would be required. Therefore, Alt+Up/Down keystrokes are declared as global shortcuts, which is not right, but that's the best I can do while being constrained by add-on API.

Is it not possible to overlay e.g. all editable controls or virtual buffer in a chooseNVDAObjectOverlayClasses function, as done for example in Outlook appModule to add features to word classes?

Some people request more configuration options, others complain there's too much. These details can be sorted out later.

I agree with you on this point.

[mltony]

@CyrilleB79 It can probably be done, but with a great deal of hacking. To the best of my knowledge, there is no good way to determine if current control is an edit box from within chooseNVDAObjectOverlayClasses , since its role hasn't been populated by the time this method is called, and so you'd end up analyzing window classes for all known edit boxes in all known applications. Injecting keystrokes into browse mode commands can be done but again, it's a hassle. In any case, this thread is not about fixing bugs in SentenceNav, especially since this bug is caused by a limitation of add-on API, and therefore it wouldn't be a problem if SentenceNav is incorporated into NVDA. You can report SentenceNav issues on its own github issue tracker.

[LeonarddeR]

@mltony : I started writing a reply to your questions, however I stopped with that when I realised that it would probably lead into more questions and more discussion. I think we're now at a point where it would help to have NV Access' opinion about the matter before continuing the discussion.

Cc @feerrenrut

[Adriani90]

Trying to come back on this, I think the discussion is prety long here. For what is worth, Tony's addon is used now for some years and as far as I know people are quite lucky with it. However, since many users ask for this to have it in the core, especially users not able to download addons, I think it make sense to consider this further. If someone still has concerns on this, maybe it can be implemented as an experimental setting. @mltony, would you like to raise a pull request to start a more efficient discussion with NV Access on the technical part of this issue? This would be highly appreciated.

[LeonarddeR]

@mltony, would you like to raise a pull request to start a more efficient discussion with NV Access on the technical part of this issue? This would be highly appreciated.

I think this request might be a bit premature as long as we have no standpoint by NV Access. @feerrenrut, would you be able to provide one?

[mltony]

I am actually going to have some time this fall and I was going to offer NVDA team to port SentenceNav and TextNav to NVDA core again. So, waiting for green light from Michael or Reef if they're interested....

[MertKaraguzel]

Hello, It is very important to reading sentence by sentence on the NVDA. I think it must come this feature. This feature must be its own feature. We should be able to read every text sentence by sentence.

[andrew-l-d]

Yes. I cannot believe that the issue is still up for debate. Reading by sentence is a major weakness of NVDA in its native form compared to other screen readers.