Individual keys to find comments and changes

[linguamortis]

When you write a document with others in MS Word, it is hard to find comments and tracked changes, because NVDA jumps to comments, changes, and spelling errors when pressing the key 'a'. When I review a Word document, I often do not want to read the changes, but only the comments. Sometimes, I want to read the changes, but not the comments. So, it would be very helpful to have indiviudal keys to find comments and to find changes, similar to the new key 'w' to find spelling errors. Otherwise, it is time consuming to find what I am looking for. Using the review panel is a solution, but it takes much longer than using a particular key.

[LeonarddeR]

I agree that, for huge documents, having only one key stroke to navigate between multiple types of annotations could be cumbersome. However, there might be a good reason why it is as it is. CC @MichaelDcurran

[dkager]

Not just for huge documents (or maybe it depends on what you would call huge). In a 10-page document the elements list is often faster to find comments among all the changes. Looking at the code, it is possible to iterate over comments and revisions separately. I would say P2.

[linguamortis]

In my opinion, having separate keys for comments and revisions would be faster than using the review panel even for 10-pages documents. Anyway, if this feature was provided, NVDA users could decide on their preferences and abilities what is more efficient.

2017-08-30 12:39 GMT+02:00, Davy Kager notifications@github.com:

Not just for huge documents (or maybe it depends on what you would call huge). In a 10-page document the elements list is often faster to find comments among all the changes. Looking at the code, it is possible to iterate over comments and revisions separately. I would say P2.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/7538#issuecomment-325952647

[LeonarddeR]

It would also be a slightly ugly fix for #7342.

Another problem is, what keys to use for this? In JAWS for example, quick navigation keys differ between browsers and word quick navigation, whereas in NVDA, quick navigation keys are universal. I prefer the latter, but it also means that we are almost out of possibilities here.

I guess we could keep a for comments, but than, we must come up with an alternative for revisions.

[dkager]

Following this convention it would have to be j, p, y or z. I like a=comment and j=revision because of their position on the QWERTY keyboard, but c=comment and r=revision would be much more intuitive.

[linguamortis]

Yes, R for review and C for comment would be more intuitive, but it would require users to relearn the key assignments. I would prefer A for review and J for comments. A user would be able to remember A for review when he or she does not remember review, but 'alteration'. For J for comment, there is not a similar association, but I think for a user it is easier to learn a new key association than it is to get used to a reassignement of keys.

Am 30.08.2017 um 14:24 schrieb Davy Kager:

Following this convention it would have to be j, p, y or z. I like a=comment and j=revision because of their position on the QWERTY keyboard, but c=comment and r=revision would be much more intuitive.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7538#issuecomment-325974231, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad-njtwtyDsvAQ2hkaLmEKdEqd7da79Tks5sdVR4gaJpZM4PFivj.

[fisher729]

Hi. We already can establish that it won't be C and R, since these are already used in browse mode quick navigation.

[bhavyashah]

Before we discuss possible key bindings further, I would like to revisit a comment quote. @leonardder wrote in https://github.com/nvaccess/nvda/issues/7538#issuecomment-325968992 "In JAWS for example, quick navigation keys differ between browsers and word quick navigation, whereas in NVDA, quick navigation keys are universal. I prefer the latter, but it also means that we are almost out of possibilities here." I too prefer the latter, but opting for it implies that a significant amount of alphabets corresponding to elements that are only found on the web and cannot be supported in a word processor, such as buttons, combo boxes, radio buttons, etc. are being wasted. While consistency is great to have, the variations in the nature of different applications suggests to me that it is necessary to have a different set of quick navigation keys for browse mode in different programs, as is the approach employed by other screen readers. Also, from a long-term standpoint, when NVDA shall implement browse mode in a wider array of software, having a consistent set of single letter navigation key commands will probably become infeasible anyways. Thoughts?

[fisher729]

Hi.

I think this is where assignment of quick navigation keys would come in handy.

On 8/31/17, bhavyashah notifications@github.com wrote:

Before we discuss possible key bindings further, I would like to revisit a comment quote. @leonardder wrote in https://github.com/nvaccess/nvda/issues/7538#issuecomment-325968992 "In JAWS for example, quick navigation keys differ between browsers and word quick navigation, whereas in NVDA, quick navigation keys are universal. I prefer the latter, but it also means that we are almost out of possibilities here." I too prefer the latter, but opting for it implies that a significant amount of alphabets corresponding to elements that are only found on the web and cannot be supported in a word processor, such as buttons, combo boxes, radio buttons, etc. are being wasted. While consistency is great to have, the variations in the nature of different applications suggests to me that it is necessary to have a different set of quick navigation keys for browse mode in different programs, as is the approach employed by other screen readers. Also, from a long-term standpoint, when NVDA shall implement browse mode in a wider array of software, having a consistent set of single letter navigation key commands will probably become infeasible anyways. Thoughts?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/nvaccess/nvda/issues/7538#issuecomment-326345317

[ruifontes]

I agree with different set of quick navigation keys for each app.

Rui

-----Mensagem Original----- De: bhavyashah Data: 31 de agosto de 2017 17:09 Para: nvaccess/nvda Cc: Subscribed Assunto: Re: [nvaccess/nvda] Individual keys to find comments and changes (#7538)

Before we discuss possible key bindings further, I would like to revisit a comment quote. @leonardder wrote in #7538 (comment) "In JAWS for example, quick navigation keys differ between browsers and word quick navigation, whereas in NVDA, quick navigation keys are universal. I prefer the latter, but it also means that we are almost out of possibilities here." I too prefer the latter, but opting for it implies that a significant amount of alphabets corresponding to elements that are only found on the web and cannot be supported in a word processor, such as buttons, combo boxes, radio buttons, etc. are being wasted. While consistency is great to have, the variations in the nature of different applications suggests to me that it is necessary to have a different set of quick navigation keys for browse mode in different programs, as is the approach employed by other screen readers. Also, from a long-term standpoint, when NVDA shall implement browse mode in a wider array of software, having a consistent set of single letter navigation key commands will probably become infeasible anyways. Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[linguamortis]

I also prefer different sets of quick navigation keys for different apps.

Is it technically feasible to provide a default set for several apps with the possibility for the users to adapt these default sets according to their preferences?

Am 01.09.2017 um 02:59 schrieb ruifontes:

I agree with different set of quick navigation keys for each app.

Rui

-----Mensagem Original----- De: bhavyashah Data: 31 de agosto de 2017 17:09 Para: nvaccess/nvda Cc: Subscribed Assunto: Re: [nvaccess/nvda] Individual keys to find comments and changes (#7538)

Before we discuss possible key bindings further, I would like to revisit a comment quote. @leonardder wrote in #7538 (comment) "In JAWS for example, quick navigation keys differ between browsers and word quick navigation, whereas in NVDA, quick navigation keys are universal. I prefer the latter, but it also means that we are almost out of possibilities here." I too prefer the latter, but opting for it implies that a significant amount of alphabets corresponding to elements that are only found on the web and cannot be supported in a word processor, such as buttons, combo boxes, radio buttons, etc. are being wasted. While consistency is great to have, the variations in the nature of different applications suggests to me that it is necessary to have a different set of quick navigation keys for browse mode in different programs, as is the approach employed by other screen readers. Also, from a long-term standpoint, when NVDA shall implement browse mode in a wider array of software, having a consistent set of single letter navigation key commands will probably become infeasible anyways. Thoughts?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7538#issuecomment-326459072, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad-njk69xLUKG44f5kHAhD6ohsReIIoEks5sd1bXgaJpZM4PFivj.

[LeonarddeR]

I still disagree here. There are still quite a lot of feasible keys around, at least on the American keyboard. These include:

• / (slash)
• backslash (backslash)
• - (dash)
• = (equals)
• [ (left bracket)
• ] (right bracket)
• . (dot)
• ` (grave)
• ; (semicolon)
• ' (apostrophe)

Some of these keys might not be available in some keyboard layouts though. Note that it is possible to override gestures on locale basis as well, though this should be avoided if possible.

Nevertheless, sounds like something that should be decided by NV Access board members.

@bhavyashah commented on 31 aug. 2017 18:09 CEST:

... elements that are only found on the web and cannot be supported in a word processor, such as buttons, combo boxes, radio buttons, etc. are being wasted.

This is incorrect. Several types of form fields are supported in Word, including edit fields, radio buttons, check boxes. It's just that they aren't yet supported by NVDA's quick navigation.

[bhavyashah]

@leonardder I had initially suspected that the factual accuracy of those examples I provided was questionable. Thanks for pointing that out. Still, we may probably want to make the best use of all our alphabets before we move on to the seemingly less intuitive symbols and punctuations. Anyways, I agree that NV Access representatives are the one who will make the verdict on the basis of all previous comments.

[mohdshara]

Two related issues here: #3687 and #6266. I think both are needed now that we are close to run out of keys.

[LeonarddeR]

Having thought about this a little more, I'm still not an advocate of separate key strokes per application, but I can live with it. I propose the general set of quick navigation keys which application can override if they so desire. So, r, for example, should default to radio button but could be overridden for Word to be revisions.

Still, my first preference is fulling up the current key strokes, j, p, y and z. It should also be considered whether all the current key strokes are still valid, given how the web develops. To give an example, frames are nowadays only used in their inline frame form, making them somehow similar to embedded objects.

[linguamortis]

More crucial than discussing which keys should be used and if there should be application-specific keys is the decision if there will or should be separate key strokes for reviews and comments or if it should remain one key for all changes in Word. I would really appreciate separate keys, no matter which ones.

Am 27.09.2017 um 14:46 schrieb Leonard de Ruijter:

Having thought about this a little more, I'm still not an advocate of separate key strokes per application, but I can live with it. I propose the general set of quick navigation keys which application can override if they so desire. So, r, for example, should default to radio button but could be overridden for Word to be revisions.

Still, my first preference is fulling up the current key strokes, j, p, y and z. It should also be considered whether all the current key strokes are still valid, given how the web develops. To give an example, frames are nowadays only used in their inline frame form, making them somehow similar to embedded objects.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7538#issuecomment-332509047, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad-njvv_k2Xi2llXOg4cizQGROVV9m9Fks5smkOmgaJpZM4PFivj.

[dkager]

Yes, for what it's worth I think the general consensus is that separate keys are useful. It would make working with the Track Changes feature in Word much easier if you could navigate through comments only or revisions only.

[linguamortis]

Yes, it would be definitely much easier with separate keys.

Am 27.09.2017 um 16:58 schrieb Davy Kager:

Yes, for what it's worth I think the general consensus is that separate keys are useful. It would make working with the Track Changes feature in Word much easier if you could navigate through comments only or revisions only.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7538#issuecomment-332549638, or mute the thread https://github.com/notifications/unsubscribe-auth/Ad-njmXcio1ch9TNBwKwLx8-4Hm8XIlKks5smmJ6gaJpZM4PFivj.

[LeonarddeR]

I'm happy to implement stuff if either @michaeldcurran or @feerrenrut agrees.

[dkager]

I'm happy to implement stuff if either @michaelDCurran or @feerrenrut agrees.

Me too. I think implementing stuff is one of the coolest things to do.

[LeonarddeR]

Heavyliy inspired as I am by the JAWS 2018 what's new, I belief we should create these quick navigation commands in any case. We can leave them unbound by default until we come up with a suitable default assignment.

[LeonarddeR]

In https://github.com/nvaccess/nvda/pull/10424: I added support for quick navigation scripts that are unbound by default.