Find On Page


Bob Cavanaugh <cavbob1993@...>
 

Luke, this is very well put. I don’t think I would have been able to explain all the technical stuff that you did just now, but I won hundred percent agree with the basic premise of your post.

On Apr 9, 2021, at 3:52 PM, Luke Davis <luke@newanswertech.com> wrote:

On Fri, 9 Apr 2021, Joseph Lee wrote:

NVDA tries its best to avoid assigning app native commands to its own functions unless a feature the app command invokes is not working well
[.]
Because Control+F is a browser command, NVDA does not assign it to its own find command.
Which raises the obvious question: is the browser find command's search feature "working well" from NVDA's prospective?

Most people probably think it doesn't, because in browse mode it has no effect.

However in focus mode, it does, in fact, work as one would expect.

You therefore have options for searching in both browse mode and focus mode: browse mode using the NVDA feature invoked by NVDA+Control+F; and in focus mode by Control+F or NVDA+Control+F.

Further, since in focus mode, the NVDA+control+F command actually invokes Control+F (I.E. the NVDA aspect is ignored), you can just learn the one command--NVDA+Control+F--and you will get the correct behavior in either mode.

I have never had cause to search in focus mode, but I can imagine circumstances where it's necessary.

Now, all that said, I think NVDA's insistence in not overriding the browser command in this circumstance is a bit pedantic.

The browser find command does not have any meaningful effect in browse mode.
Therefore, it is not "working well", as Joseph says.
Furthermore, browse mode is an NVDA layer over the browser, that is not browser native. However it looks browser native as far as most users are concerned.
The more user friendly option here would be to provide Control+F as the find feature invocation in browse mode. We see on this list, in this discussion and others, how much confusion it causes; and since browse mode is its own, non-browser, layer over the page, we wouldn't really be overriding the browser's command, which is only effective in focus mode.

Fortunately, this is not hard to remap in input gestures, if you are so inclined.

But that's just one user's opinion, and differs from my usual "learn the right way" thought process.

Luke





 

Hi,
In focus mode, Control+NVDA+F "appears" to invoke Control+F - that's because
whatever key that's assigned to NVDA key is passed straight to the
app/document you are interacting; for example, if Insert key is assigned as
NVDA modifier key, when you press Control+NVDA+F while in focus mode, what
the web browser will see will be Control+Insert+F.
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Luke Davis
Sent: Friday, April 9, 2021 3:52 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

On Fri, 9 Apr 2021, Joseph Lee wrote:

NVDA tries its best to avoid assigning app native commands to its own
functions unless a feature the app command invokes is not working well
[.]
Because Control+F is a browser command, NVDA does not assign it to its own
find command.

Which raises the obvious question: is the browser find command's search
feature "working well" from NVDA's prospective?

Most people probably think it doesn't, because in browse mode it has no
effect.

However in focus mode, it does, in fact, work as one would expect.

You therefore have options for searching in both browse mode and focus mode:

browse mode using the NVDA feature invoked by NVDA+Control+F; and in focus
mode by Control+F or NVDA+Control+F.

Further, since in focus mode, the NVDA+control+F command actually invokes
Control+F (I.E. the NVDA aspect is ignored), you can just learn the one
command--NVDA+Control+F--and you will get the correct behavior in either
mode.

I have never had cause to search in focus mode, but I can imagine
circumstances
where it's necessary.

Now, all that said, I think NVDA's insistence in not overriding the browser
command in this circumstance is a bit pedantic.

The browser find command does not have any meaningful effect in browse mode.
Therefore, it is not "working well", as Joseph says.
Furthermore, browse mode is an NVDA layer over the browser, that is not
browser
native. However it looks browser native as far as most users are concerned.
The more user friendly option here would be to provide Control+F as the find

feature invocation in browse mode. We see on this list, in this discussion
and
others, how much confusion it causes; and since browse mode is its own,
non-browser, layer over the page, we wouldn't really be overriding the
browser's
command, which is only effective in focus mode.

Fortunately, this is not hard to remap in input gestures, if you are so
inclined.

But that's just one user's opinion, and differs from my usual "learn the
right
way" thought process.

Luke


Gene
 

Also, consider that for someone withh movement problems, using NVDA key f may cause problems. I agree with Luke but I would put it a different way. It is ideology triumphing over what works well, has positive consequences and no negative ones that I can think of. A principle can be overdone.

However, if a change were made, both commands should work. So many people use NVDA f now that it should not be dropped. Control f would be added as another browse mode find command.

Gene

-----Original Message-----
From: Bob Cavanaugh
Sent: Friday, April 09, 2021 5:59 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

Luke, this is very well put. I don’t think I would have been able to explain all the technical stuff that you did just now, but I won hundred percent agree with the basic premise of your post.
On Apr 9, 2021, at 3:52 PM, Luke Davis <luke@newanswertech.com> wrote:

On Fri, 9 Apr 2021, Joseph Lee wrote:

NVDA tries its best to avoid assigning app native commands to its own functions unless a feature the app command invokes is not working well
[.]
Because Control+F is a browser command, NVDA does not assign it to its own find command.
Which raises the obvious question: is the browser find command's search feature "working well" from NVDA's prospective?

Most people probably think it doesn't, because in browse mode it has no effect.

However in focus mode, it does, in fact, work as one would expect.

You therefore have options for searching in both browse mode and focus mode: browse mode using the NVDA feature invoked by NVDA+Control+F; and in focus mode by Control+F or NVDA+Control+F.

Further, since in focus mode, the NVDA+control+F command actually invokes Control+F (I.E. the NVDA aspect is ignored), you can just learn the one command--NVDA+Control+F--and you will get the correct behavior in either mode.

I have never had cause to search in focus mode, but I can imagine circumstances where it's necessary.

Now, all that said, I think NVDA's insistence in not overriding the browser command in this circumstance is a bit pedantic.

The browser find command does not have any meaningful effect in browse mode.
Therefore, it is not "working well", as Joseph says.
Furthermore, browse mode is an NVDA layer over the browser, that is not browser native. However it looks browser native as far as most users are concerned.
The more user friendly option here would be to provide Control+F as the find feature invocation in browse mode. We see on this list, in this discussion and others, how much confusion it causes; and since browse mode is its own, non-browser, layer over the page, we wouldn't really be overriding the browser's command, which is only effective in focus mode.

Fortunately, this is not hard to remap in input gestures, if you are so inclined.

But that's just one user's opinion, and differs from my usual "learn the right way" thought process.

Luke





Luke Davis
 

On Fri, 9 Apr 2021, Joseph Lee wrote:

In focus mode, Control+NVDA+F "appears" to invoke Control+F - that's because
whatever key that's assigned to NVDA key is passed straight to the
app/document you are interacting
My apology, I should have said it invokes the find feature, not invokes control+F.

Although, my point in that side comment holds, I think--NVDA+Control+F, no matter which NVDA modifier you use, does in fact invoke the browser find feature when in focus mode, at least in the browsers I've tested (Firefox, Brave, Edge).

To me using NVDA+Control+F in both places is a less reasonable thing to do than remapping the NVDA browse mode find key to Control+F, but I'm all about options.

My larger argument was that in browse mode (though I admit to being far from any expert on virtual buffers and tree interceptions), users aren't directly interacting with the browser. The browser find in the browse mode context is not a feature that performs any useful function, as far as I can tell, so why expose it?
Assuming that is a valid point, if we stop exposing it, what then prevents us from using the same key (Control+F) to perform browse mode finds? We wouldn't be (aren't now) obscuring or duplicating some useful feature of the browser.

Luke


Steve Nutt
 

Hi Bob,

I believe System Access did what JAWS does.

If you press Control F in JAWS and virtual cursor is on, JAWS assumes a JAWS find. So if you really did want to do the browser's version of find, you'd have to turn off the virtual cursor in JAWS.

You can see this, because JAWS says the words JAWS find when the dialogue comes up.

NVDA on the other hand behaves in my view better, because it doesn't make that assumption.

All the best

Steve

--
To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribe

Computer Room Services
77 Exeter Close
Stevenage
Hertfordshire
SG1 4PW
T: +44(0)1438-742286
M: +44(0)7956-334938
F: +44(0)1438-759589
E: steve@comproom.co.uk
W: https://www.comproom.co.uk

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Bob Cavanaugh
Sent: 09 April 2021 19:46
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

That was a much more technical answer than I was looking for, but between yours and Brian's, I think I understand. In the case of controls with no actual text that NVDA has to extract, I completely understand where the NVDA find could be useful. That being said though, is the fact that NVDA actually uses a virtual cursor in browse mode the reason the control+F command never works, even when searching for plain text? I doubt I'll ever find out for sure, but Joseph, your programming knowledge may shed some light into how System Access possibly worked when it comes to this issue. Because I used that screen reader the most, it's where I have most of my experience finding things, and control+F worked. I would imagine it had to have some form of browse Vs. focus mode, but the end user never had to choose because every time it encountered an input, particularly an edit field, it automatically switched. That could be annoying at times as I had to tab out of an edit field before I could navigate to the next one, but it also helped at times, as there was one site I had to use when I was in school where both NVDA and JAWS automatically went into focus mode upon logging in, which made navigating by the quick keys I was used to impossible, but it wasn't an issue at all with System Access.

On 4/8/21, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi,

I guess I need to go deeper into the layered design I mentioned in my
last reply (the best person to explain the browser side of things is
Marco Zehe from Mozilla Foundation):

To let NVDA navigate a website as though you are reading a document,
NVDA employs what’s called a “tree interceptor”. A tree interceptor is
a collection of elements that act like one large text area. Because a
tree interceptor is a collection of elements and texts coming from
these, it can include hundreds of different controls of varying roles
(straight text, form fields, links, frames, web apps, video players,
you name it). Using a tree to describe a complex control such as a web
document is quite an interesting approach – after all, graphical user
interface elements are organized like a tree or branches, with web
documents consisting of a collection of smaller elements (and this is
how HTML and ARIA coding is actually rendered on screen).

But tree interceptors are not enough. NVDA relies on three more
materials to create a completely functioning browse mode
implementation: virtual buffers, accessibility API’s, and a cursor
manager (there are other elements involved, but these three are
essential). Virtual buffers create building blocks for documents.
Accessibility API’s and standards such as IAccessible and ARIA (Accessible Rich Internet Applications) enhance the “look and feel”
of a browse mode document. Finally, cursor managers provide commands
to move around the just created browse mode document.

The steps NVDA takes when creating a browse mode document are as follows:

1. You start a web browser. NVDA can then load appropriate support modules
based on the browser you are using.
2. You open a new website.
3. When NVDA detects that a new page is open, NVDA will either use API’s
provided by the web browser to gather information about the just
opened document (typically UIA browse mode implementations in Chromium
Edge) or ask a DLL that ships with NVDA to gather info on the fly
(Firefox is a good example of this).
4. Whatever method is chosen, NVDA will read the document from top to
bottom, constructing NVDA objects to represent elements found in the
web document. At the same time, texts coming from these web elements
are gathered into a single browse mode document (tree interceptor in
some cases) to facilitate navigation, first letter commands, NVDA
find, elements list and a whole host of features.



As for NVDA find command, NVDA will search text of the browse mode
document (stored internally) and will place the cursor at the next
occurrence of the searched term.

P.S. Marco, if you are here, may I ask if you can shed some light on
browse mode/tree interceptor internals? I can speak of what NVDA does
at the high level.

Cheers,

Joseph





From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian
Vogel
Sent: Thursday, April 8, 2021 8:27 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page



Bob,

Before I start even trying to explain this, it would be
helpful to know what browser or browsers you and Glenn are using and
where either one of these finds is not working.

I am going to try to make the distinction between a browser
find and a screen reader find (and it doesn't matter whether it's JAWS
or NVDA) as simple as I can. I can assure you that I will be omitting
scads of "under the hood" detail that someone far more knowledgeable
about both browser internals and NVDA internals can delve in to if they so choose.

A browser find focuses on what can be seen on a page
that's a part of the page text. That is generally limited to actual
text as well as text used for click-through links and labels. But
text on controls, like buttons, checkboxes, etc., will very often not
be found using a browser find. Much of this depends on how sloppy the
page coders have been about how certain controls are written and
what's exposed to a browser find versus a screen reader find. I also
believe that a browser find does not examine the virtual cursor used
by the screen reader while a screen reader find does just that.

As a result, there can be differences in not only what
can be found by either one, but exactly where the screen reader focus
is after each is done.

I tend to favor the screen reader find when someone's
using a screen reader simply because it tends to find certain things
that a browser find doesn't, and you more often have focus on the
thing just found, consistently, with a screen reader find.

I'm actually hoping someone with way more "under the hood"
knowledge will chime in and probably bore some of us silly getting
into the actual differences between how a browser find and screen
reader find works and can explain the discrepancies not only in what
each can find but in where focus lies after each. I have never been
able to come up with any precise way of describing what's different between the two.
--

Brian - Windows 10 Pro, 64-Bit, Version 20H2, Build 19042

Always remember others may hate you but those who hate you don't win
unless you hate them. And then you destroy yourself.

~ Richard M. Nixon











Steve Nutt
 

No, because people may want to use the browser find function for their own reasons.

I like Joseph, don't believe in blocking app specific functions with a screen reader.

All the best

Steve

--
To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribe

Computer Room Services
77 Exeter Close
Stevenage
Hertfordshire
SG1 4PW
T: +44(0)1438-742286
M: +44(0)7956-334938
F: +44(0)1438-759589
E: steve@comproom.co.uk
W: https://www.comproom.co.uk

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Bob Cavanaugh
Sent: 09 April 2021 20:11
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

This in principal makes sense. However, when searching for plain text on a webpage, wouldn't it make sense to use the browser's find command rather than the screen reader specific one?

On 4/9/21, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi,
NVDA tries its best to avoid assigning app native commands to its own
functions unless a feature the app command invokes is not working well
(Excel's cell comment (F2) command is a good example of this exception
where Excel's own cell comments dialog isn't quite useful). Because
Control+F is a browser command, NVDA does not assign it to its own
find command. At first, this may seem counterintuitive, but when you
consider the fact that you must learn app commands in addition to screen reader commands, it makes sense:
let NVDA do its best at what it does, and let apps do what they do the
best (this principle is sometimes called "separation of concerns").
P.S. Although not really related to the immediate concern, when I
write app modules and need to create commands for NVDA users, I do my
best to avoid app native keyboard shortcuts.
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Bob
Cavanaugh
Sent: Friday, April 9, 2021 11:46 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

That was a much more technical answer than I was looking for, but
between yours and Brian's, I think I understand. In the case of
controls with no actual text that NVDA has to extract, I completely
understand where the NVDA find could be useful. That being said
though, is the fact that NVDA actually uses a virtual cursor in browse
mode the reason the control+F command never works, even when searching
for plain text? I doubt I'll ever find out for sure, but Joseph, your
programming knowledge may shed some light into how System Access
possibly worked when it comes to this issue. Because I used that
screen reader the most, it's where I have most of my experience
finding things, and control+F worked. I would imagine it had to have
some form of browse Vs. focus mode, but the end user never had to
choose because every time it encountered an input, particularly an
edit field, it automatically switched. That could be annoying at times
as I had to tab out of an edit field before I could navigate to the
next one, but it also helped at times, as there was one site I had to
use when I was in school where both NVDA and JAWS automatically went
into focus mode upon logging in, which made navigating by the quick keys I was used to impossible, but it wasn't an issue at all with System Access.

On 4/8/21, Joseph Lee <joseph.lee22590@gmail.com> wrote:
Hi,

I guess I need to go deeper into the layered design I mentioned in my
last reply (the best person to explain the browser side of things is
Marco Zehe from Mozilla Foundation):

To let NVDA navigate a website as though you are reading a document,
NVDA employs what’s called a “tree interceptor”. A tree interceptor
is a collection of elements that act like one large text area.
Because a tree interceptor is a collection of elements and texts
coming from these, it can include hundreds of different controls of
varying roles (straight text, form fields, links, frames, web apps,
video players, you name it). Using a tree to describe a complex
control such as a web document is quite an interesting approach –
after all, graphical user interface elements are organized like a
tree or branches, with web documents consisting of a collection of
smaller elements (and this is how HTML and ARIA coding is actually rendered on screen).

But tree interceptors are not enough. NVDA relies on three more
materials to create a completely functioning browse mode
implementation: virtual buffers, accessibility API’s, and a cursor
manager (there are other elements involved, but these three are
essential). Virtual buffers create building blocks for documents.
Accessibility API’s and standards such as IAccessible and ARIA
(Accessible Rich Internet Applications) enhance the “look and feel”
of a browse mode document. Finally, cursor managers provide commands
to move around the just created browse mode document.

The steps NVDA takes when creating a browse mode document are as follows:

1. You start a web browser. NVDA can then load appropriate support
modules
based on the browser you are using.
2. You open a new website.
3. When NVDA detects that a new page is open, NVDA will either use API’s
provided by the web browser to gather information about the just
opened document (typically UIA browse mode implementations in
Chromium
Edge) or ask a DLL that ships with NVDA to gather info on the fly
(Firefox is a good example of this).
4. Whatever method is chosen, NVDA will read the document from top to
bottom, constructing NVDA objects to represent elements found in the
web document. At the same time, texts coming from these web elements
are gathered into a single browse mode document (tree interceptor in
some cases) to facilitate navigation, first letter commands, NVDA
find, elements list and a whole host of features.



As for NVDA find command, NVDA will search text of the browse mode
document (stored internally) and will place the cursor at the next
occurrence of the searched term.

P.S. Marco, if you are here, may I ask if you can shed some light on
browse mode/tree interceptor internals? I can speak of what NVDA does
at the high level.

Cheers,

Joseph





From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Brian
Vogel
Sent: Thursday, April 8, 2021 8:27 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page



Bob,

Before I start even trying to explain this, it would be
helpful to know what browser or browsers you and Glenn are using and
where either one of these finds is not working.

I am going to try to make the distinction between a
browser find and a screen reader find (and it doesn't matter whether
it's JAWS or NVDA) as simple as I can. I can assure you that I will
be omitting scads of "under the hood" detail that someone far more
knowledgeable about both browser internals and NVDA internals can
delve in to if they so choose.

A browser find focuses on what can be seen on a page
that's a part of the page text. That is generally limited to actual
text as well as text used for click-through links and labels. But
text on controls, like buttons, checkboxes, etc., will very often not
be found using a browser find. Much of this depends on how sloppy
the page coders have been about how certain controls are written and
what's exposed to a browser find versus a screen reader find. I also
believe that a browser find does not examine the virtual cursor used
by the screen reader while a screen reader find does just that.

As a result, there can be differences in not only what
can be found by either one, but exactly where the screen reader focus
is after each is done.

I tend to favor the screen reader find when someone's
using a screen reader simply because it tends to find certain things
that a browser find doesn't, and you more often have focus on the
thing just found, consistently, with a screen reader find.

I'm actually hoping someone with way more "under the hood"
knowledge will chime in and probably bore some of us silly getting
into the actual differences between how a browser find and screen
reader find works and can explain the discrepancies not only in what
each can find but in where focus lies after each. I have never been
able to come up with any precise way of describing what's different
between the two.
--

Brian - Windows 10 Pro, 64-Bit, Version 20H2, Build 19042

Always remember others may hate you but those who hate you don't win
unless you hate them. And then you destroy yourself.

~ Richard M. Nixon




















Luke Davis
 

Steve Nutt wrote:

No, because people may want to use the browser find function for their own reasons.
Can you speculate what one of those reasons might be? Since in speech and braille its results can not, afaik, be accessed?

I like Joseph, don't believe in blocking app specific functions with a screen reader.
Well, I've already made my argument about browse mode effectively not being the browser, which is why in this rare case, I don't agree with that view. I won't rehash that.

Luke


Glenn / Lenny
 

Regardless of whether it is interfering with the app or not the thing is that it has never worked right, for me or anyone I've seen try to use it.
It should just take you to what you are looking for on the page.
To me, that is what has kept NVDA from being a very useful tool in the tool box, although it is always there, I seldom go for NVDA, because I use the find on page many times a day.
I think more folks should use it on web pages, but most people don't use web pages as much, and as proficiently as they should.
Glenn


Chris Smart
 

are you using CTRL+F or NVDA+CTRL+F? I always use the latter and it seems to work fine.



On 2021-04-16 1:16 p.m., Glenn / Lenny wrote:
Regardless of whether it is interfering with the app or not the thing is that it has never worked right, for me or anyone I've seen try to use it.
It should just take you to what you are looking for on the page.
To me, that is what has kept NVDA from being a very useful tool in the tool box, although it is always there, I seldom go for NVDA, because I use the find on page many times a day.
I think more folks should use it on web pages, but most people don't use web pages as much, and as proficiently as they should.
Glenn


Gene
 

Find on page is used when control f is used and is not what should be used with NVDA. Use NVDA key f for the find dialog and it will work properly. If you are using the correct find, you will hear find dialog, not find on page.

Gene

-----Original Message-----
From: Glenn / Lenny
Sent: Friday, April 16, 2021 12:16 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page


Regardless of whether it is interfering with the app or not the thing is that it has never worked right, for me or anyone I've seen try to use it.
It should just take you to what you are looking for on the page.
To me, that is what has kept NVDA from being a very useful tool in the tool box, although it is always there, I seldom go for NVDA, because I use the find on page many times a day.
I think more folks should use it on web pages, but most people don't use web pages as much, and as proficiently as they should.
Glenn


Glenn / Lenny
 

I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.
It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.
Glenn


Gene
 

Since that isn't expected behavior, that is a problem with your system but it can't be generalized to be an NVDA problem. I don't know what causes it but if you were using another computer, you shouldn't have the problem.

If you haven't tried another browser, doing so might solve the problem as well.

Gene

-----Original Message-----
From: Glenn / Lenny
Sent: Friday, April 16, 2021 3:09 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page


I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.
It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.
Glenn


benmoxey@...
 

Hi Glenn

 

First, it is important to ensure you are in Browse mode, otherwise the standard browser Find will activate. Press NVDA + Space to toggle between Browse and Focus mode.

 

To clarify the commands:

  • NVDA + Control + F performs an NVDA find on the page.
  • NVDA + F3 will find the next instance of what you searched for.
  • NVDA + Shift + F3 will find the previous instance of what you searched for.

 

These commands should be working reliably in Google Chrome, Microsoft Edge, Firefox etc.

 

Hope this helps.

 

Cheers

 

Ben

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Glenn / Lenny
Sent: Saturday, 17 April 2021 6:09 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

 

I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.

It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.

Glenn


Luke Davis
 

Glenn, if you keep forgetting this, go to NVDA's input gestures dialog, and in browse mode gestures, change the key to control+f.

The repeat gesture will still be NVDA+F3.

Luke

Glenn / Lenny wrote:

I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.
It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.
--
Luke

"In this life there are obstacles, and forces who overcome obstacles. You can be either one or the other.
If you refuse to even try to clear an obstacle, you become the obstacle."
- Joel Shepherd


Chris Mullins
 

Hi

Note also that if you trigger the find in page feature, it opens a Find bar which you should close before switching to browse mode and using the NVDA+Ctrl+f command.  When the find bar opens, press tab and you should find a buttn to close it.  

 

Cheers

Chris

Sent from Mail for Windows 10

 

From: benmoxey@...
Sent: 16 April 2021 22:40
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

 

Hi Glenn

 

First, it is important to ensure you are in Browse mode, otherwise the standard browser Find will activate. Press NVDA + Space to toggle between Browse and Focus mode.

 

To clarify the commands:

  • NVDA + Control + F performs an NVDA find on the page.
  • NVDA + F3 will find the next instance of what you searched for.
  • NVDA + Shift + F3 will find the previous instance of what you searched for.

 

These commands should be working reliably in Google Chrome, Microsoft Edge, Firefox etc.

 

Hope this helps.

 

Cheers

 

Ben

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Glenn / Lenny
Sent: Saturday, 17 April 2021 6:09 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

 

I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.

It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.

Glenn

 


 

luke,
can you please teach me input gestures remotely?
i tested one time and up arrow key stopped working for me and i could
not go to the previous item.
i am afraid to test again and work with input gesture again to learn it.

On 4/17/21, Luke Davis <luke@newanswertech.com> wrote:
Glenn, if you keep forgetting this, go to NVDA's input gestures dialog, and
in
browse mode gestures, change the key to control+f.

The repeat gesture will still be NVDA+F3.

Luke

Glenn / Lenny wrote:

I have always tried both control + F and then when I remember/rediscover
that it doesn't work, I try insert + control + F and that never works
right either.
It should take me to the word, and F3 should repeat it, but it does
something, but the word is nowhere around my cursor.
--
Luke

"In this life there are obstacles, and forces who overcome obstacles. You
can be either one or the other.
If you refuse to even try to clear an obstacle, you become the obstacle."
- Joel Shepherd





--
By God,
were I given all the seven heavens
with all they contain
in order that
I may disobey God
by depriving an ant
from the husk of a grain of barley,
I would not do it.
imam ali


Steve Nutt
 

Hi,

 

Should be NVDA Key Plus F3, not just F3 to repeat the find.

 

All the best


Steve

 

--

To subscribe to our News and Special Offers list, go to https://www.comproom.co.uk/subscribe

 

Computer Room Services

77 Exeter Close

Stevenage

Hertfordshire

SG1 4PW

T: +44(0)1438-742286

M: +44(0)7956-334938

F: +44(0)1438-759589

E: steve@...

W: https://www.comproom.co.uk

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Glenn / Lenny
Sent: 16 April 2021 21:09
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

 

I have always tried both control + F and then when I remember/rediscover that it doesn't work, I try insert + control + F and that never works right either.

It should take me to the word, and F3 should repeat it, but it does something, but the word is nowhere around my cursor.

Glenn