Re: Find On Page

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 <> wrote:

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

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



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


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

Join to automatically receive all group messages.