Find On Page


Glenn / Lenny
 

Hi All,
A fellow lister suggested that I try this without any add-ons running, but I haven't tried that yet.
Here's the issue:
I use control + F to find something on a web page or document with Jaws just fine, but that never works with NVDA.
I've tried insert + control F too and it does not work.
It seems to act as though it did the search, but it does not place me on the page at what I searched for.
In fact, this has never worked for me, I'm sure even before I ever installed any addons.
I just assumed over the years that maybe NVDA does not do this.
When it does work for someone, does it actually move the reading cursor to the spot, or does it say it found something and leave a dialog box open?
I don't know if NVDA has done that before, or if it was something else, but I'm expecting the reading cursor to go to the first instance of my search, as Jaws does.
 
Thanks for any help.
 
Glenn


Gene
 

Control f is not the find command for NVDA. its control NVDA key f. the default NVDA key is the insert using the desktop layout. I believe it also works in the laptop layout.

the reading position should move to the result. I don't know if this still happens in recent versions, but in old versions of NVDA, at times I have to do a search twice because the first time, the reading position doesn't change properly, if at all. But this happens on and off and if you consistently aren't moved to the proper position, I don't know what is causing the problem.

Gene

-----Original Message-----
From: Glenn / Lenny
Sent: Thursday, April 08, 2021 8:32 PM
To: nvda@nvda.groups.io
Subject: [nvda] Find On Page


Hi All,
A fellow lister suggested that I try this without any add-ons running, but I haven't tried that yet.
Here's the issue:
I use control + F to find something on a web page or document with Jaws just fine, but that never works with NVDA.
I've tried insert + control F too and it does not work.
It seems to act as though it did the search, but it does not place me on the page at what I searched for.
In fact, this has never worked for me, I'm sure even before I ever installed any addons.
I just assumed over the years that maybe NVDA does not do this.
When it does work for someone, does it actually move the reading cursor to the spot, or does it say it found something and leave a dialog box open?
I don't know if NVDA has done that before, or if it was something else, but I'm expecting the reading cursor to go to the first instance of my search, as Jaws does.

Thanks for any help.

Glenn


 

On Thu, Apr 8, 2021 at 09:52 PM, Gene wrote:
Control f is not the find command for NVDA. its control NVDA key f.
-
Indeed, but it appears the questioner has described using browser find (CTRL+F) and NVDA Find (NVDA+CTRL+F) and neither is working as expected.  Why that would be, I cannot say, since browser find or NVDA find both work for me (and many others) when either is used, depending on what, exactly one is trying to do.

I have suggested trying:  The Most Basic Troubleshooting Steps for Suspected NVDA Issues
as a starting point.
 
--

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

 


Gene
 

It would be interesting to know if the person has used more than one computer. the person said the problem has gone back for years. While I wouldn't think a computer problem would result in this behavior, it still would be good to know.

Gene

-----Original Message-----
From: Brian Vogel
Sent: Thursday, April 08, 2021 9:02 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

On Thu, Apr 8, 2021 at 09:52 PM, Gene wrote:
Control f is not the find command for NVDA. its control NVDA key f.-
Indeed, but it appears the questioner has described using browser find (CTRL+F) and NVDA Find (NVDA+CTRL+F) and neither is working as expected. Why that would be, I cannot say, since browser find or NVDA find both work for me (and many others) when either is used, depending on what, exactly one is trying to do.

I have suggested trying: The Most Basic Troubleshooting Steps for Suspected NVDA Issues
as a starting point.

--


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


Bob Cavanaugh <cavbob1993@...>
 

Brian,
What is the difference between browser find and NVDA find? It seems
odd to me that control+F does not work in NVDA as expected when I've
had no issues with it in any other screen reader. I would suggest a
change here, but I have no idea what would need to be changed.

On 4/8/21, Brian Vogel <britechguy@gmail.com> wrote:
On Thu, Apr 8, 2021 at 09:52 PM, Gene wrote:


Control f is not the find command for NVDA. its control NVDA key f.
-
Indeed, but it appears the questioner has described using browser find
(CTRL+F) and NVDA Find (NVDA+CTRL+F) and neither is working as expected.
Why that would be, I cannot say, since browser find or NVDA find both work
for me (and many others) when either is used, depending on what, exactly one
is trying to do.

I have suggested trying: The Most Basic Troubleshooting Steps for Suspected
NVDA Issues ( https://nvda.groups.io/g/nvda/message/81494 )
as a starting point.

--

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






 

Hi,
Control+NVDA+F is active whenever browse mode is active. This means find command will work on web browsers, some Microsoft Office applications, and in certain apps that supports browse mode functionality.
Whereas browser find (Control+F) will list search results and does not move browse mode cursor (at least in Edge), Control+NVDA+F works in conjunction with browse mode cursor and will actually move the cursor to the first character of a result. This mechanism is valid wherever browse mode is supported. Internally, NVDA find command is implemented as part of what's called a "cursor manager" - a facility where cursor movement in complex documents such as web documents are specified. On top of this, NVDA may add browse mode support, with app-specific customizations on top. How NVDA can support browse mode for many apps from a common core is beyond the scope of this list, but suffice to say that a layered design is employed, and that's what makes it possible to use NVDA find facility across apps.
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Bob Cavanaugh
Sent: Thursday, April 8, 2021 7:53 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

Brian,
What is the difference between browser find and NVDA find? It seems odd to me that control+F does not work in NVDA as expected when I've had no issues with it in any other screen reader. I would suggest a change here, but I have no idea what would need to be changed.

On 4/8/21, Brian Vogel <britechguy@gmail.com> wrote:
On Thu, Apr 8, 2021 at 09:52 PM, Gene wrote:


Control f is not the find command for NVDA. its control NVDA key f.
-
Indeed, but it appears the questioner has described using browser find
(CTRL+F) and NVDA Find (NVDA+CTRL+F) and neither is working as expected.
Why that would be, I cannot say, since browser find or NVDA find both
work for me (and many others) when either is used, depending on what,
exactly one is trying to do.

I have suggested trying: The Most Basic Troubleshooting Steps for
Suspected NVDA Issues ( https://nvda.groups.io/g/nvda/message/81494 )
as a starting point.

--

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
 

Hi Glenn, it's been quite a long time.

Yes, it takes you directly to the result, no dialog box.

As others have said, NVDA+control+f is what you want here.

However, since it seems you may have tried that (you said Control+insert+f, but that's the same thing if you have your insert key set as the NVDA key), some debugging steps:

First, do you have "enable browse mode on page load" checked, in the browse mode settings? You can reach the browse mode settings by pressing NVDA+control+b, then tabbing to the option.
If you don't, please check it, then press enter, and again try to do a search with NVDA+control+f.

Can you tell us what browser you are using?

Can you please give an example of a page you go to (so we can go there), and a term you search for to which you expect to be taken but aren't (so we can search for it)?

Luke

On Thu, 8 Apr 2021, Glenn / Lenny wrote:

I use control + F to find something on a web page or document with Jaws just fine, but that never works with NVDA.
I've tried insert + control F too and it does not work.
It seems to act as though it did the search, but it does not place me on the page at what I searched for.
In fact, this has never worked for me, I'm sure even before I ever installed any addons.
I just assumed over the years that maybe NVDA does not do this.
When it does work for someone, does it actually move the reading cursor to the spot, or does it say it found something and leave a dialog box open?
I don't know if NVDA has done that before, or if it was something else, but I'm expecting the reading cursor to go to the first instance of my search, as
Jaws does.


Gene
 

JAWS reassigns that command to work with the virtual pc cursor. Window-eyes didn't use control f either. it used Control shift f.

Browsers have their own find command, usually control f. But the virtual PC cursor or browse mode is not using the browser find command because when you move through a page using the virtual pc cursor or browse mode, you are using a virtual cursor, there is no cursor on the actual page. A sighted person looks at the page and reads what is there. He doesn't move through a page with a cursor. He can scroll down, causing new text to appear on the screen, but there is no cursor. You don't need a cursor if you are just reading and aren't intended to edit anything. The reason you can move around a web page as though you were in a word processor is because the screen-reader simulates a cursor. If it didn't, you couldn't properly move in a web page to read what you want and skip what you want.

When you use the browser's find command, you are telling the virtual cursor to move to the find result.

Gene

-----Original Message-----
From: Bob Cavanaugh
Sent: Thursday, April 08, 2021 9:52 PM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Find On Page

Brian,
What is the difference between browser find and NVDA find? It seems
odd to me that control+F does not work in NVDA as expected when I've
had no issues with it in any other screen reader. I would suggest a
change here, but I have no idea what would need to be changed.

On 4/8/21, Brian Vogel <britechguy@gmail.com> wrote:
On Thu, Apr 8, 2021 at 09:52 PM, Gene wrote:


Control f is not the find command for NVDA. its control NVDA key f.
-
Indeed, but it appears the questioner has described using browser find
(CTRL+F) and NVDA Find (NVDA+CTRL+F) and neither is working as expected.
Why that would be, I cannot say, since browser find or NVDA find both work
for me (and many others) when either is used, depending on what, exactly one
is trying to do.

I have suggested trying: The Most Basic Troubleshooting Steps for Suspected
NVDA Issues ( https://nvda.groups.io/g/nvda/message/81494 )
as a starting point.

--

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






 

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

 


 

My apologies to Gene, Joseph, and Luke.  I read Bob's question, started my reply, walked away, and never reloaded to check to see what might have come between when I walked away and got back.  I've covered territory already covered previously.
--

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

 


 

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

 


 

Hi,

Don’t worry – at least it gave us a chance to go deeper this time.

Cheers,

Joseph

 

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

 

My apologies to Gene, Joseph, and Luke.  I read Bob's question, started my reply, walked away, and never reloaded to check to see what might have come between when I walked away and got back.  I've covered territory already covered previously.
--

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

 


Rui Fontes
 

By the way, I normally read small PDF files in MS Edge...

NVDA+Control+F do not work on those files...


Rui Fontes


Às 04:15 de 09/04/2021, Luke Davis escreveu:

Hi Glenn, it's been quite a long time.

Yes, it takes you directly to the result, no dialog box.

As others have said, NVDA+control+f is what you want here.

However, since it seems you may have tried that (you said Control+insert+f, but that's the same thing if you have your insert key set as the NVDA key), some debugging steps:

First, do you have "enable browse mode on page load" checked, in the browse mode settings? You can reach the browse mode settings by pressing NVDA+control+b, then tabbing to the option.
If you don't, please check it, then press enter, and again try to do a search with NVDA+control+f.

Can you tell us what browser you are using?

Can you please give an example of a page you go to (so we can go there), and a term you search for to which you expect to be taken but aren't (so we can search for it)?

Luke


On Thu, 8 Apr 2021, Glenn / Lenny wrote:

I use control + F to find something on a web page or document with Jaws just fine, but that never works with NVDA.
I've tried insert + control F too and it does not work.
It seems to act as though it did the search, but it does not place me on the page at what I searched for.
In fact, this has never worked for me, I'm sure even before I ever installed any addons.
I just assumed over the years that maybe NVDA does not do this.
When it does work for someone, does it actually move the reading cursor to the spot, or does it say it found something and leave a dialog box open?
I don't know if NVDA has done that before, or if it was something else, but I'm expecting the reading cursor to go to the first instance of my search, as
Jaws does.



Bob Cavanaugh <cavbob1993@...>
 

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











 

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











Bob Cavanaugh <cavbob1993@...>
 

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




















 

Hi,
Brian might be able to answer this one better, but to screen readers, all they care about app shortcuts is the ability of follow-up actions to provide useful and interpretable data (focus events, data that is actually interpretable by NVDA, etc.). Also, as Brian stated, what Control+F finds is the text as the browser itself interprets, and what NVDA does when you press Control+NVDA+F is searching for what can be gathered from its own browse mode document, and in some cases, moves the system focus to the just found element. It somewhat transcends element types (roles), because even for plain text, NVDA must use browse mode logic to render in a way that's navigable by users (this is why there are settings about maximum line length and page length in browse mode settings so NVDA can render text according to your own idea of how large a "page" should be).
Cheers,
Joseph

-----Original Message-----
From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Bob Cavanaugh
Sent: Friday, April 9, 2021 12:11 PM
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




















 

On Fri, Apr 9, 2021 at 03:11 PM, Bob Cavanaugh wrote:
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?
-
Well, to me it doesn't simply because of the "irregular focus behavior" that occurs using the browser find.  You're not the only one who's experienced this.  What you get out of the screen reader find, regardless of screen reader, is generally more of "what you'd expect" when doing a find as far as focus goes.

That's why I strongly favor the screen reader find when using a screen reader, although I still always have clients turn on the feature that causes the focus on the actual screen to be highlighted based on what corresponds to it in the virtual cursor.  When you're used to seeing where you actually are on the page, it's very easy to become disoriented very quickly when there is no scrolling for the actual screen while you've traveled a long way away from what's currently got focus in the virtual cursor.  Under NVDA that's was the Focus Highlight Add-On now the Focus Highlight feature built into the screen reader itself.  Right now the terminology that JAWS uses for this functionality is escaping me.
 
--

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

 


Gene
 

No. You aren't working directly with the web page when you are in browse mode, also called by JAWS the virtual PC cursor. The text is in a buffer. You use the browse mode search because it searches the text in the buffer and moves the virtual cursor to the occurrence of the text.

If you use the find command the browser provides, you are telling the browser to ssearch the actual page, not the text in the buffer.
You will therefore not get proper results.


Gene.

-----Original Message-----
From: Bob Cavanaugh
Sent: Friday, April 09, 2021 2:11 PM
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
 

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