This in principal makes sense. However, when searching for plain text
toggle quoted messageShow quoted 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 <email@example.com> 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
(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.
From: firstname.lastname@example.org <email@example.com> On Behalf Of Bob Cavanaugh
Sent: Friday, April 9, 2021 11:46 AM
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 <firstname.lastname@example.org> 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 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
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.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Brian
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
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