Date   

Re: [Solved] Activating the Mouse with NVDA

Luke Davis
 

Back to the original issue, David Russell wrote:

Gene, and all, the problem occurs with this application form, (see
sample in my previous post) that each question has the "choose one"
command. The combo-box may be embedded on the line that says, choose
one.
Along with the excellent suggestions from others, may I suggest that when you get to the line with the combo box on it, you press the letter f, to jump to the next formfield? This might move you to whatever these combo boxes are.
Then try the space key to "activate" them (or do as others have suggested).

I do remind you to check your browse mode settins, and make sure you have "use browse mode on page load" checked. Also perhaps uncheck the one before it: "use screen layout when supported".
I described the first of these in an earlier message to you.

> I was using page down and enter, or enter and page down to

I'm not sure where you got page down in this context, but I'm pretty sure it has no value for moving between or within fields, and in fact will make you miss lots of content.

If I down arrow, as in the sample sent, other questions follow until
the end and one reads
Continue
Continue should say "button" after it. If it doesn't, your settings are very strange.

Luke, I am reluctant to try the thing you suggested in NVDA tools, I
am unaware of that feature.
It's in the user manual. And it can't hurt anything.
But that's your choice.

Luke


Re: update on Firefox with NVDA

Luke Davis
 

Sharni-Lee Ward wrote:

So it's true that the latest update makes Firefox nigh unusable?
No.

It's true that some people, on some systems, looking at some websites, have runaway CPU and/or memory usage with Firefox some of the time.

If you're not having this already, you probably aren't going to have it after updating either Firefox or NVDA.

I, who have had this issue at multiple times, on multiple computers, haven't had it in the last few versions of either NVDA or Firefox. I also suspect I haven't used any of the sites which cause it lately.

So I don't think there is any cause to fear this issue striking you, if it hasn't already.

Luke


Re: Find On Page

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


Re: Find On Page

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





Re: Find On Page

 

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


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





Re: Find On Page

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


Re: Find On Page

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




















Re: Find On Page

 

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

 


Re: [Solved] Activating the Mouse with NVDA

David Moore
 

I was totally blind in high school in the early '80s! I learned then, that the Slash and star keys Ment divide or multiply! I don't remember how, either someone told me, but I did a lot of calculations on in IBM PC in the middle 80s. I cannot imagine that a totally blind person could use a computer for any length of time and not know that! This concerns me a great deal! I have always had many sided friends, family, and others describing things for me! I believe that is the root problem here for so many blind individuals. They do not have enough sided people in their life describing and interacting with what they do as a blind person. I have cited friends who I have taught English one Braille to, alphabet and numbers, and they can use a slate and stylus. These friends are so interested in how I do things. I think we need to learn how a sided person sees, does, and how the sided persons experience is when they work with technology. It really helps me, I know that, to visualize in if I know how a screen of a phone looks to a sided person, it helps me so much to visualize that in my head. Caveat, though, I did have a little reading vision until I was 12. Maybe that is the entire difference for me, I don't know! I actually learned as a child how everything looked like in print! I wonder if that makes a difference right there! Take care guys, very interesting discussion.


On Fri, Apr 9, 2021, 5:56 PM Gene <gsasner@...> wrote:
I see no reason to believe I am unique.  I took a good training course, I
looked at screen-reader documentation in the late nineties when I was first
learning Windows, and I didn't have the slash and star keys described as
divide or multiply.  I learned it later, I don't recall how.  for all I
know, I may have learned it by using the key describer.  On what do you base
your contention or assumption that blind computer users generally know this?

All I said is that the keys be identified as both when discussing mouse
movement.  that is not unreasonable, given what I suspect is the experience
of a good many blind people.  If your impression is based on formerly
sighted people knowing this, that isn't a valid basis.  People who were
blind when they start learning about computers may well not have been taught
these numpad keys as mathematical functions.

Gene
-----Original Message-----
From: Brian Vogel
Sent: Friday, April 09, 2021 11:57 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Activating the Mouse with NVDA

On Fri, Apr 9, 2021 at 12:49 PM, Sarah k Alawami wrote:
I don't use, and have never used a number pad-
Which, Sarah, makes you a member of a very tiny minority of computer users,
sighted or blind.   Again, knowing when one is far from the mean in a bell
curve distribution is a pretty vital skill.

One does not create documentation "for the masses" that covers each and
every rare eventuality.  In fact, if one wants it to be as succinct as
possible, one avoids doing precisely that.
--


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











Re: [Solved] Activating the Mouse with NVDA

Gene
 

Evidently, you are saying you don't find a combo box or any structure corresponding to those lines. That's what I wanted to clarify. Your talk of using page down or enter and page down is confusing because that isn't the way to open combo boxes. You use enter on a combo box to go into forms mode or turn off browse mode, whatever your screen-reader calls it. If a combo box contains java script, once you are in forms mode. the command to open the combo box is control down arrow. You never use page down for this purpose with or without control. If you wish, you can issue the open command on any combo box whether it uses JAVA Script or not, though it will only affect the operation if it has JAVA script.

Since you are saying that you see no combo box, it may be there but not accessible to a screen-reader. You may not be able to work with it.

I have two suggestions. They are worth trying, but I'm doubtful they will work.

One is to try another browser and another screen-reader. You never know what the result might be. To discuss which other browser would be good to try, we have to know which one you are using now.

Here is the other suggestion:
If you are using JAWS, turn off the virtual PC cursor with JAWS key z. Now, tab and see if you see a combo box you didn't see before. Once you have finished looking, use the same command, JAWS key z to turn on the virtual pc cursor again.

If you are using NVDA, use the command NVDA key space to do the same thing and tab as discussed above. When finished, use the same command, NVDA space bar, to turn on browse mode again.

Gene

-----Original Message-----
From: David Russell
Sent: Friday, April 09, 2021 12:04 PM
To: nvda@nvda.groups.io
Subject: [nvda] Activating The Mouse CT

Hello NVDA,

Gene, and all, the problem occurs with this application form, (see
sample in my previous post) that each question has the "choose one"
command. The combo-box may be embedded on the line that says, choose
one.
I was using page down and enter, or enter and page down to force the
combo-box to open on earlier application questions, such as address,
city, and state; the state to choose was in a combo-box.
I had to often repeat page down enter, or enter page down, to get it
to behave as wanted.

If I down arrow, as in the sample sent, other questions follow until
the end and one reads
Continue
I guess the question is more how to force a combo-box to open if it is
truly embedded.

Luke, I am reluctant to try the thing you suggested in NVDA tools, I
am unaware of that feature.

Sorry to hear that shift-control-f doesn't work, but will try Jackie's
suggestion, NVDA-enter on the line in question.
Cheers,

David
--
David C. Russell, Author
david.sonofhashem@gmail.com


Re: [Solved] Activating the Mouse with NVDA

Gene
 

I see no reason to believe I am unique. I took a good training course, I looked at screen-reader documentation in the late nineties when I was first learning Windows, and I didn't have the slash and star keys described as divide or multiply. I learned it later, I don't recall how. for all I know, I may have learned it by using the key describer. On what do you base your contention or assumption that blind computer users generally know this?

All I said is that the keys be identified as both when discussing mouse movement. that is not unreasonable, given what I suspect is the experience of a good many blind people. If your impression is based on formerly sighted people knowing this, that isn't a valid basis. People who were blind when they start learning about computers may well not have been taught these numpad keys as mathematical functions.

Gene

-----Original Message-----
From: Brian Vogel
Sent: Friday, April 09, 2021 11:57 AM
To: nvda@nvda.groups.io
Subject: Re: [nvda] Activating the Mouse with NVDA

On Fri, Apr 9, 2021 at 12:49 PM, Sarah k Alawami wrote:
I don't use, and have never used a number pad-
Which, Sarah, makes you a member of a very tiny minority of computer users, sighted or blind. Again, knowing when one is far from the mean in a bell curve distribution is a pretty vital skill.

One does not create documentation "for the masses" that covers each and every rare eventuality. In fact, if one wants it to be as succinct as possible, one avoids doing precisely that.
--


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


Re: [Solved] Activating the Mouse with NVDA

Sarah k Alawami
 

Nope. I don't even bother learning it. Right now due to my brain issue I tend to forget as soon as I'm told, and I have to repeat things probably 20 or 30 times until I get it. But I'm one who will just stick with what I know to avoid any stress on my battered brain.

For the person with the truly embedded combo box if you tab can you then hit alt down arrow to open the "one" combo box and hope it is the right one when looking at context?

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 9 Apr 2021, at 14:12, Chris Smart wrote:

Ok, I just hope you can teach the other keyboard style as well.

Even the notebook I use sometimes has a numpad.



On 2021-04-09 5:09 p.m., Sarah k Alawami wrote:

I have. I hate it. It was on a desktop in 2009 or so. I turned off desktop nav and used laptop layout as for me it is much much faster. My hands get tired easily so if I don't have to move them a lot, that is good. I can work longer hours doing what I love.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 9 Apr 2021, at 9:54, Chris Smart wrote:

Gosh, you should try a full-size keyboard sometime.




On 2021-04-09 12:49 p.m., Sarah k Alawami wrote:

Actually it's not knowledge for me. I don't use, and have never used a number pad so I just assumed that they were known as slash and dash. Not devide and minus. Same with star and times. I never actually had a sighted person draw them out with wiki sticks for me to feel. Or, maybe I did when I was little but I don't remember.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 8 Apr 2021, at 15:56, Brian Vogel wrote:

Gene,

If someone wishes to write it this way, have at it.  But we're back to one of those things on which we're likely to never agree.  I believe that very common conventions, across many forms of documentation, for referring to number pad keys need to be known by "the average computer user."  It is no help to make documentation longer, and more complicated, assuming that this is not something commonly known, in my opinion.

Asterisk as the multiply operator and slash as the divide operator predate the PC, and have been in use in that way on many adding machines for decades now, particularly after the PC appeared.

Numpad multiply and numpad divide need to be understood under those terms, and I'd rather the rare person who doesn't already know them do what Mr. Russell did and ask.  There's nothing wrong with having a very occasional gap in common knowledge and asking to fill it in.
--

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

 


Re: Word, reading table description

benmoxey@...
 

Hi Sandra

 

  1. Activate Browse mode by using the toggle, NVDA + space.
  2. Press NVDA + D )(for delta) from within the table.

 

Cheers

 

Ben

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of Sandra Pilz
Sent: Saturday, 10 April 2021 6:47 AM
To: nvda@nvda.groups.io
Subject: [nvda] Word, reading table description

 

Hello,

 

When I create a table in Microsoft word, provide an alternative text and a description in the table properties, NVDA will announce the alternative Text as I navigate to the table and it will also say "has description". However, I am not sure what I would need to do in order to hear or read the description. Can someone help?

 

Thank you.

 

Sandra


Re: [Solved] Activating the Mouse with NVDA

Chris Smart
 

Ok, I just hope you can teach the other keyboard style as well.

Even the notebook I use sometimes has a numpad.



On 2021-04-09 5:09 p.m., Sarah k Alawami wrote:

I have. I hate it. It was on a desktop in 2009 or so. I turned off desktop nav and used laptop layout as for me it is much much faster. My hands get tired easily so if I don't have to move them a lot, that is good. I can work longer hours doing what I love.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 9 Apr 2021, at 9:54, Chris Smart wrote:

Gosh, you should try a full-size keyboard sometime.




On 2021-04-09 12:49 p.m., Sarah k Alawami wrote:

Actually it's not knowledge for me. I don't use, and have never used a number pad so I just assumed that they were known as slash and dash. Not devide and minus. Same with star and times. I never actually had a sighted person draw them out with wiki sticks for me to feel. Or, maybe I did when I was little but I don't remember.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 8 Apr 2021, at 15:56, Brian Vogel wrote:

Gene,

If someone wishes to write it this way, have at it.  But we're back to one of those things on which we're likely to never agree.  I believe that very common conventions, across many forms of documentation, for referring to number pad keys need to be known by "the average computer user."  It is no help to make documentation longer, and more complicated, assuming that this is not something commonly known, in my opinion.

Asterisk as the multiply operator and slash as the divide operator predate the PC, and have been in use in that way on many adding machines for decades now, particularly after the PC appeared.

Numpad multiply and numpad divide need to be understood under those terms, and I'd rather the rare person who doesn't already know them do what Mr. Russell did and ask.  There's nothing wrong with having a very occasional gap in common knowledge and asking to fill it in.
--

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

 


Re: [Solved] Activating the Mouse with NVDA

Sarah k Alawami
 

I have. I hate it. It was on a desktop in 2009 or so. I turned off desktop nav and used laptop layout as for me it is much much faster. My hands get tired easily so if I don't have to move them a lot, that is good. I can work longer hours doing what I love.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 9 Apr 2021, at 9:54, Chris Smart wrote:

Gosh, you should try a full-size keyboard sometime.




On 2021-04-09 12:49 p.m., Sarah k Alawami wrote:

Actually it's not knowledge for me. I don't use, and have never used a number pad so I just assumed that they were known as slash and dash. Not devide and minus. Same with star and times. I never actually had a sighted person draw them out with wiki sticks for me to feel. Or, maybe I did when I was little but I don't remember.

--

Sarah Alawami, owner of TFFP. . For more info go to our website.

Check out my adventures with a shadow machine.

to subscribe to the feed click here and you can also follow us on twitter

Our discord is where you will know when we go live on twitch. Feel free to give the channel a follow and see what is up there.

For stream archives, products you can buy and more visit my main lbry page and my tffp lbry page You will also be able to buy some of my products and eBooks there.

Finally, to become a patron and help support the podcast go here

On 8 Apr 2021, at 15:56, Brian Vogel wrote:

Gene,

If someone wishes to write it this way, have at it.  But we're back to one of those things on which we're likely to never agree.  I believe that very common conventions, across many forms of documentation, for referring to number pad keys need to be known by "the average computer user."  It is no help to make documentation longer, and more complicated, assuming that this is not something commonly known, in my opinion.

Asterisk as the multiply operator and slash as the divide operator predate the PC, and have been in use in that way on many adding machines for decades now, particularly after the PC appeared.

Numpad multiply and numpad divide need to be understood under those terms, and I'd rather the rare person who doesn't already know them do what Mr. Russell did and ask.  There's nothing wrong with having a very occasional gap in common knowledge and asking to fill it in.
--

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

 


Word, reading table description

Sandra Pilz
 

Hello,


When I create a table in Microsoft word, provide an alternative text and a description in the table properties, NVDA will announce the alternative Text as I navigate to the table and it will also say "has description". However, I am not sure what I would need to do in order to hear or read the description. Can someone help?


Thank you.


Sandra


Re: Find On Page

 

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




















Re: Find On Page

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




















Re: Find On Page

 

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










2201 - 2220 of 85176