In Browse mode, an easier key should be bound to find, find next, and find previous.

[derekriemer]

As discussed on IRC: Currently, to bring up find, the user has to do finger gymnastics. Several NVDA power users have switched their find commands to / in the input gestures dialog, because it is faster. While it's not perfect because the user can sometimes (if they are an extremely fast typer) type faster than the dialog comes up, it's much easier to use. We also discussed something like [ and ] or ; and ' being next/previous find by default. however we are in a shortage for keys, so maybe nvda+slash for forward and shift+slash or shift+nvda+slash for backward. cc @tspivey @jcsteh @camlorn

[derekriemer]

If this is made into quick nav, we might also want to announce "no previous/next find" rather than bringing up a dialog.

[jcsteh]

I agree with the idea in general. However, I'm concerned about intuitive UX here. Slash might make sense for search, but NVDA+slash or similar seems kinda ugly and suffers from the same problem you're trying to fix here.

It's worth noting that some time ago, I argued against overriding control+f, etc. because it overrides the application's own commands. While that's still true, those commands aren't useful for NVDA users as they stand now in web browsers. However, one concern is that disabling single letter navigation should probably disable these new commands. That's fine for slash, but if we wanted to use f3 or shift+f3 for find next/previous, for example, that won't work because those keys aren't characters and thus don't count as single letter nav.

Btw, we still don't want to override control+f because the native find dialog is useful in Microsoft Word.

P4 because this might be a nice to have, but there's already a way to do this and it's well established.

[Adriani90]

i discovered that nvda+z and nvda+x are not assigned yet. How about assigning them by default as search previous (nvda+z) and search next (nvda+x)?

[Adriani90]

cc: @marlon-sousa your thoughts on this are very appreciated. Congrats to the pull request regarding the search terms history in the find dialog!

[marlon-sousa]

here are my thoughts: I think that user experience is imperative. althoug i dislike nvda ctrl f more than I can express here, I understand perfectly why the authors opted for not overriding ctrl f and think that they are right and that all of power users including me got used to the wrong way because of other Screen readers. But, in the other hand, I think we have a very good solution using / and shift plus / in quick navigation mode. This way, Nuete users can still use the common NVDA CTRL f while more advanced ones can go faster by pressing only the / key. What frustrates me more though is the fact that search wrapping is not active at the moment, and most parts of times we just need to find something on the page it doesn’t matter if it is under or above the cursor. This Will be my next pull request: implement search wrapping.

[lukaszgo1]

@marlon-sousa Search wrapping is covered by #4637 I've expressed my opinion in the last comment of this issue, so I am not going to repeat myself, just wanted to say that I hope you would make it configurable.

[marlon-sousa]

Be sure that it will .. if my promosal is accepted. Nothing I code is not configurable.

Obrigado, Marlon

Em 22 de mar de 2019, à(s) 19:39, Łukasz Golonka notifications@github.com escreveu:

@marlon-sousa Search wrapping is covered by #4637 I've expressed my opinion in the last comment of this issue, so I am not going to repeat myself, just wanted to say that I hope you would make it configurable.

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

[aaclause]

i discovered that nvda+z and nvda+x are not assigned yet. How about assigning them by default as search previous (nvda+z) and search next (nvda+x)?

I'd prefer a single key (with shift key for the backward search). Indeed NVDA+{x,z} is not intuitive/fast in my mind. However, it is always easier than pressing NVDA+{f3,shift+f3}. In my user configuration, I've assigned 'j' for search next and "shift+j" for search previous.

[Adriani90]

@Andre9642 how did you assign the command for find next / previous?

[aaclause]

@Adriani90 under – Preferences > Input Gestures > Browse mode > find the {previous,next} occurrence of the previously entered text string from the current cursor's position –.

[Adriani90]

Closing this as not planned due to lack of community support in #16383.

[marlon-sousa]

@Adriani90 feel free to bring this to Enhanced Find Dialog if you wish and then we can further discuss it.

[CyrilleB79]

@Adriani90, you have closed this issue with the following justification:

Closing this as not planned due to lack of community support in #16383.

This issue had not been discussed in the last 5 years. Then, within 10 hours, you have opened a PR providing a particular solution, received some feedback and closed it. This seems to me a very short period to make conclusions. Moreover, the reactions in #16383 have been made on the basis of the implementation you have provided. If needed, some alternative solutions may be found, e.g. using other keys, etc. At least, it deserves being discussed further IMO. Thus I'll reopen to have at least NV Access' opinion; NV Access please have a look at the comments in #16383. Cc @seanbudd

More generally, I feel we are here at the limit of what can be done and what should not be done by collaborators in charge of triaging the issues. If possible, I'd like NV Access to tell us if closing this issue was a good triage action or not, so that we can better fulfill NV Access' expectations in the future. Thanks. Cc @seanbudd, @gerald-hartig

[Adriani90]

I actually just found #3439. It seems enabling sticky keys in Windows settings makes already life much easier in such cases. I didn't know that feature exists in windows.

With this in mind I think still this issue can be closed.

[Adriani90]

Maybe we should note such things in the NVDA user guide as well, at least the accessibility parts of Windows that directly have a positive effect on NVDA.

[Adriani90]

Closing due to Windows providing sticky keys feature. If the community insists on implementing a NVDA specific solution, please comment with strong arguments and we can reopen.

[XLTechie]

@Adriani90 wrote:

Maybe we should note such things in the NVDA user guide as well, at least the accessibility parts of Windows that directly have a positive effect on NVDA.

A separate issue, but it does seem worth pursuing.

[CyrilleB79]

Closing due to Windows providing sticky keys feature. If the community insists on implementing a NVDA specific solution, please comment with strong arguments and we can reopen.

I do not think that sticky keys are the solution. Sticky keys is an accessibility feature for people having dexterity issues. The result is that they do not need to press modifiers along with the main key of a shortcut but can press sequentially the modifiers one by one and then the main key. If sticky keys are enabled, whenever you press two keys simultaneously, the feature is disabled. Thus when sticky keys feature is enabled, you need to always press keys (modifiers + main key) sequentially.

On the contrary, my understanding of the current issue is that it is not specifically requested by people having dexterity issues. But these people want to have a more handy shortcut for find actions which are considered quite common and frequent. They are probably not against more complex shortcuts for the less frequent actions, e.g. NVDA+control+shift+F1.

@Adriani90, more generally, I have the feeling that closing an issue providing a solution when we are not sure that it is suitable for the submitter can be perceived as a lack of consideration from the submitter. Thus, I'll re-open; I hope you do not mind.

If we have no feedback from the submitter or other users during one or two months, we can close again, considering that the issue is probably not so important.

@derekriemer please comment here to explain your problem and use case more specifically. Or if you finally consider it's not so important, let us also know. Thanks.