Screen Refresh


David Kingsbury
 

Hi all,

JAWS has a keystroke for refreshing the screen (Insert Escape). Does NVDA have a keystroke for doing the same thing?

Thanks,

David

 

 


David Goldfield
 

Hi. Pressing the NVDA key with f5 does a refresh although it’s likely a refresh of the virtual buffer as opposed to an actual screen refresh.

 

 

David Goldfield,

Blindness Assistive Technology Specialist

NVDA Certified Expert

 

Subscribe to the Tech-VI announcement list to receive news, events and information regarding the blindness assistive technology field.

Email: tech-vi+subscribe@groups.io

www.DavidGoldfield.org

 

From: nvda@nvda.groups.io <nvda@nvda.groups.io> On Behalf Of David Kingsbury
Sent: Saturday, July 9, 2022 12:01 PM
To: nvda@groups.io
Subject: [nvda] Screen Refresh

 

Hi all,

JAWS has a keystroke for refreshing the screen (Insert Escape). Does NVDA have a keystroke for doing the same thing?

Thanks,

David

 

 


Gene
 

Not that I know of.  I just searched the quick commands reference to see if I could find one and a search for refresh found nothing.  However,

it appears to me that NVDA usually doesn't need the screen refreshed, while JAWS does more often.  When do you want to refresh the screen, in Browse mode or at other times?

Gene

On 7/9/2022 11:00 AM, David Kingsbury wrote:

Hi all,

JAWS has a keystroke for refreshing the screen (Insert Escape). Does NVDA have a keystroke for doing the same thing?

Thanks,

David

 

 



Gene
 

Not that I know of.  I just searched the quick commands reference to see if I could find one and a search for refresh found nothing.  However,

it appears to me that NVDA usually doesn't need the screen refreshed, while JAWS does more often.  When do you want to refresh the screen, in Browse mode or at other times?

Gene

On 7/9/2022 11:00 AM, David Kingsbury wrote:

Hi all,

JAWS has a keystroke for refreshing the screen (Insert Escape). Does NVDA have a keystroke for doing the same thing?

Thanks,

David

 

 



Brian's Mail list account
 

Most browsers can have their pages refreshed, but in many cases it says it cannot withoutsending data you already inputted or that the page has expired. If we are talking ordinary software. That should not be required. Most problems I find are due to the software not playing well with a screenreader when content is changed. Brian

--
bglists@...
Sent via blueyonder.(Virgin media)
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.

----- Original Message -----
From: "Gene" <gsasner@...>
To: <nvda@nvda.groups.io>
Sent: Saturday, July 09, 2022 5:04 PM
Subject: Re: [nvda] Screen Refresh


Not that I know of. I just searched the quick commands reference to see
if I could find one and a search for refresh found nothing. However,

it appears to me that NVDA usually doesn't need the screen refreshed,
while JAWS does more often. When do you want to refresh the screen, in
Browse mode or at other times?

Gene

On 7/9/2022 11:00 AM, David Kingsbury wrote:

Hi all,

JAWS has a keystroke for refreshing the screen (Insert Escape). Does
NVDA have a keystroke for doing the same thing?

Thanks,

David






Gene
 

Most pages don't present that message about resending data.  I believe they tend to be pages in which you enter data such as survey pages.

My comments about JAWS versus NVDA refer to the problem that at times in the virtual PC cursor, when text changes on a page, if you don't refresh the virtual PC buffer, you continue to see old text.  I don't use JAWS to any extent now and I don't recall when this tends to happen but I've seen it more with JAWS than with NVDA where it seldom happens.  In the case where it happens in NVDA, I believe that alt tabbing to another window than alt tabbing back causes the browse mode buffer to refresh.
I'd have to check that.

Gene
On 7/10/2022 4:07 AM, Brian's Mail list account via groups.io wrote:

Most browsers can have their pages refreshed, but in many cases it says it cannot withoutsending data you already inputted or that the page has expired. If we are talking ordinary software. That should not be required. Most problems I find are due to the software not playing well with a screenreader when content is changed. Brian



Gene
 

I just tried alt tabbing away from a page, then alt tabbing back and the buffer didn't appear to refresh.  It didn't appear to refresh when I turned browse mode off, then on again.  People having a problem may wish to try those things, in case they work.  Fortunately, I have either never or almost never had a problem where I needed to refresh the display using NVDA.

Gene

On 7/10/2022 9:12 AM, Gene wrote:

Most pages don't present that message about resending data.  I believe they tend to be pages in which you enter data such as survey pages.

My comments about JAWS versus NVDA refer to the problem that at times in the virtual PC cursor, when text changes on a page, if you don't refresh the virtual PC buffer, you continue to see old text.  I don't use JAWS to any extent now and I don't recall when this tends to happen but I've seen it more with JAWS than with NVDA where it seldom happens.  In the case where it happens in NVDA, I believe that alt tabbing to another window than alt tabbing back causes the browse mode buffer to refresh.
I'd have to check that.

Gene
On 7/10/2022 4:07 AM, Brian's Mail list account via groups.io wrote:
Most browsers can have their pages refreshed, but in many cases it says it cannot withoutsending data you already inputted or that the page has expired. If we are talking ordinary software. That should not be required. Most problems I find are due to the software not playing well with a screenreader when content is changed. Brian




 
Edited

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph


Dave Grossoehme
 

Hi:  What happens when you press the f5 key?  That is an old windows key stroke to refresh the web page.

Dave


On 7/10/2022 10:12 AM, Gene wrote:

Most pages don't present that message about resending data.  I believe they tend to be pages in which you enter data such as survey pages.

My comments about JAWS versus NVDA refer to the problem that at times in the virtual PC cursor, when text changes on a page, if you don't refresh the virtual PC buffer, you continue to see old text.  I don't use JAWS to any extent now and I don't recall when this tends to happen but I've seen it more with JAWS than with NVDA where it seldom happens.  In the case where it happens in NVDA, I believe that alt tabbing to another window than alt tabbing back causes the browse mode buffer to refresh.
I'd have to check that.

Gene
On 7/10/2022 4:07 AM, Brian's Mail list account via groups.io wrote:
Most browsers can have their pages refreshed, but in many cases it says it cannot withoutsending data you already inputted or that the page has expired. If we are talking ordinary software. That should not be required. Most problems I find are due to the software not playing well with a screenreader when content is changed. Brian



Dave Grossoehme
 

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave


On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph


Gene
 

According to what I've read, f5 refreshes the page, in other words, it reloads it but it does so from the cache.  To refresh the cache of the page as well as reload it, control f5 will do that. 

In NVDA, it appears that NVDA key f5 refreshes the screen, but I'm not sure of that.  That may be what the original person was asking to do but if it does that, there is only a refresh screen command in Browse Mode.

Input help says that NVDA f5 refreshes the document content.  I'm not sure what that means, but that is what I am speculating refreshes the screen.

Gene
On 7/12/2022 9:45 AM, Dave Grossoehme wrote:

Hi:  What happens when you press the f5 key?  That is an old windows key stroke to refresh the web page.

Dave


On 7/10/2022 10:12 AM, Gene wrote:
Most pages don't present that message about resending data.  I believe they tend to be pages in which you enter data such as survey pages.

My comments about JAWS versus NVDA refer to the problem that at times in the virtual PC cursor, when text changes on a page, if you don't refresh the virtual PC buffer, you continue to see old text.  I don't use JAWS to any extent now and I don't recall when this tends to happen but I've seen it more with JAWS than with NVDA where it seldom happens.  In the case where it happens in NVDA, I believe that alt tabbing to another window than alt tabbing back causes the browse mode buffer to refresh.
I'd have to check that.

Gene
On 7/10/2022 4:07 AM, Brian's Mail list account via groups.io wrote:
Most browsers can have their pages refreshed, but in many cases it says it cannot withoutsending data you already inputted or that the page has expired. If we are talking ordinary software. That should not be required. Most problems I find are due to the software not playing well with a screenreader when content is changed. Brian




Gene
 

If you lose connection with the Internet, no page that has finished downloading to the browser is lost.  When you open a web page, it is downloaded to the browser and it stays there, whether you are online or not, until you close the tab or window containing the page in the browser itself.

If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.

This has nothing to do with the speed of the Internet, it depends on what happens when contact with a site or the Internet is interrupted.

Gene

On 7/12/2022 10:06 AM, Dave Grossoehme wrote:

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave


On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph



 

On Tue, Jul 12, 2022 at 11:15 AM, Gene wrote:
If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.
-
Just for the record, this depends on the site itself and how it's coded.

A great example is Groups.io itself.  If I am disconnected from the internet (whether early during a page download, or immediately before trying to go to another page) I'll get one of the classic error message pages.  But as soon as connectivity is restored, it reloads itself without my having to do anything.

Not all web pages behave similarly, and those that "self reload" are in the minority, but they do exist.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill


Dave Grossoehme
 

Jean that can depend on how many pages are already opened.  It also depends on the internet speed and how many nanosecond that the outage was for.  It's possible to loose one or many of the pages in the process that Joseph explained about in a prior message where communication has to go between the browser and the screen reader for you to read.  That is also going to depend on how much memory is in the computer, and if there are other applications open as well.  In that case you could loose one page that was beiong read or all pages that were open.  I have had cases where it drops all and you have to start over. 

Dave


On 7/12/2022 11:15 AM, Gene wrote:

If you lose connection with the Internet, no page that has finished downloading to the browser is lost.  When you open a web page, it is downloaded to the browser and it stays there, whether you are online or not, until you close the tab or window containing the page in the browser itself.

If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.

This has nothing to do with the speed of the Internet, it depends on what happens when contact with a site or the Internet is interrupted.

Gene

On 7/12/2022 10:06 AM, Dave Grossoehme wrote:

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave


On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph



Dave Grossoehme
 

Hi Bryan:  Sorry I got ahead of you here.  I didn't see your message until I had already sent mine.  In that case, if there is any disagreement in thought here, please give me the benefit of the doubt.  However, we agree on your statement.

Dave



On 7/12/2022 11:20 AM, Brian Vogel wrote:

On Tue, Jul 12, 2022 at 11:15 AM, Gene wrote:
If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.
-
Just for the record, this depends on the site itself and how it's coded.

A great example is Groups.io itself.  If I am disconnected from the internet (whether early during a page download, or immediately before trying to go to another page) I'll get one of the classic error message pages.  But as soon as connectivity is restored, it reloads itself without my having to do anything.

Not all web pages behave similarly, and those that "self reload" are in the minority, but they do exist.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill


 

Dave,

No problem.   I'm still at a bit of a loss to even understand what all the hubbub is about.  This sort of thing does happen, if not constantly, then at least often enough that we all encounter it.

I've never seen an instance where using the browser's own reload current page button doesn't get things right back to where they need to be (whether a screen reader is part of the mix or not).  That's why that function exists in every browser I've ever used.  It's not a screen reader function, per se, nor should it be.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill


Gene
 

I'm not sure what conditions you are referring to.  You don't lose already downloaded pages.  I don't recall what conditions Joseph Lee was referring to.

Gene

On 7/12/2022 10:25 AM, Dave Grossoehme wrote:

Jean that can depend on how many pages are already opened.  It also depends on the internet speed and how many nanosecond that the outage was for.  It's possible to loose one or many of the pages in the process that Joseph explained about in a prior message where communication has to go between the browser and the screen reader for you to read.  That is also going to depend on how much memory is in the computer, and if there are other applications open as well.  In that case you could loose one page that was beiong read or all pages that were open.  I have had cases where it drops all and you have to start over. 

Dave


On 7/12/2022 11:15 AM, Gene wrote:
If you lose connection with the Internet, no page that has finished downloading to the browser is lost.  When you open a web page, it is downloaded to the browser and it stays there, whether you are online or not, until you close the tab or window containing the page in the browser itself.

If you are downloading something and you lose contact with the Internet briefly or very briefly, I'm not sure if the download stops or resumes, though I think it stops.

This has nothing to do with the speed of the Internet, it depends on what happens when contact with a site or the Internet is interrupted.

Gene

On 7/12/2022 10:06 AM, Dave Grossoehme wrote:

Hi Joseph:  Don

't forget about the speed of the web here.  What's going to happen with all these actions, if the internet skips a beat, and goes out for a part of a second but not long enough for the computer to loose all the pages that are open with a multipage document open as well as other documents. 

Dave


On 7/10/2022 11:41 AM, Joseph Lee wrote:

[Edited Message Follows]

Hi,

Here's why:

Suppose a screen reader went great lengths to obtain content for whatever page you are browsing. Now suppose that, somehow, the screen reader forgets what it was looking at when you switch screens (windows/apps). If the screen reader switches back to the web browser you were using, it doesn't remember what the page "looked" like, so it goes great lengths again to obtain document content.

Now suppose that you are browsing multiple websites, perhaps using tabs to do so. Because the screen reader does not remember content you were looking at whenever screens (or tabs) are changed, the screen reader must figure out where it is, whatever it is looking at, and ask the web browser for browse mode content. Suppose this happens so quickly that you notice the screen reader is slow to respond, and a bug is filed about it.

The task performed by a screen reader to obtain browse mode content is, as a Mozilla engineer put it, "swallowing the document". That is, in order for NVDA to obtain information from a web document and convert it into a suitable representation, it needs to ask the web browser for raw document content. This takes time depending on how responsive the web browser is to requests from other apps (including NVDA) and the length of the document. It goes something like this:

  1. User (to web browser): I want to browse to a particular website.
  2. Browser (to user, after a pause): okay, here is the document you have requested.
  3. NVDA (to web browser): but wait, the user is blind, so I need a way to present the document in a suitable way.
  4. Web browser (to NVDA): what do you want me to do for you?
  5. NVDA (to web browser): I'm going to send a messenger (no joke), and you are supposed to send the raw document (complete with HTML and other code) to them.
  6. Web browser (depending on the browser the user is using): okay, I will wait for you (old browser)/hey, I gave you all the tools you need (accessibility API's for instance), so why are you asking me to give you raw content (new browser)?
  7. NVDA messenger (to web browser): here I am, give me the raw document content please.
  8. Web browser (to NVDA messenger, after gathering the raw document content in a suitable form): here it is.
  9. NVDA messenger (to NVDA): okay, I did what you've asked.
  10. NVDA (to NVDA messenger): well done, I will tell my user about it.
  11. NVDA (to user): Loading document...
  12. NVDA (to user, after the document is formatted): here it is (then starts reading from the top if the user says so).
  13. NVDA (to self): phew, that was a long trip. I don't want to go through this again. Wait, I have a notebook which I can use to jot down document content.

The bottlenecks are the messenger and subsequent document formatting steps.

Technical: the "messenger" in this interaction is a piece of NVDA called Remote Helper, a DLL called upon to inject itself into other processes (programs) for various tasks. An important task this DLL does is ask web browsers for raw document content, which is then passed onto NVDA so it can convert it into a browse mode representation. Newer web browsers are concerned about code injection, so they do their best to provide the web document in a documented way, and one such effort is IAccessible2. In theory, using an API to access web document should eliminate the need for document refreshing (NVDA+F5 in browse mode) whenever content changes, which is different than screen refreshing in JAWS (JAWS key+Escape).

Hope this answers a lot of questions.

Cheers,

Joseph




Gene
 

I've seen many times in JAWS when the buffer does not refresh when the screen refreshes and you see old information.  I have to use the screen refresh command in JAWS, JAWS key escape, when that occurs.  At times, such as when filling out a form, if I refreshed the page, I would lose information I entered.  If this ever happens in NVDA, I have seldom, if ever seen it happen but it appears that NVDA key f5 does the same thing as the JAWS command, refreshes the buffer browse mode uses.

This is a proper function of a screen-reader because the problem is in the screen-reader and it is not desirable to refresh the actual page.

Gene

On 7/12/2022 10:46 AM, Brian Vogel wrote:

Dave,

No problem.   I'm still at a bit of a loss to even understand what all the hubbub is about.  This sort of thing does happen, if not constantly, then at least often enough that we all encounter it.

I've never seen an instance where using the browser's own reload current page button doesn't get things right back to where they need to be (whether a screen reader is part of the mix or not).  That's why that function exists in every browser I've ever used.  It's not a screen reader function, per se, nor should it be.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill



Dave Grossoehme
 

Hi:  No it isn't just in the one application.  As Joseph explained in his message within the last 24 hours, it's in the communication of the browser and the screen reader and the API that are making the communications between the web site and the browser and the screen reader.  As Bryan said in an earlier message it also depends on the language used for the web page as to whether it will refresh or not. 

Dave


On 7/12/2022 12:32 PM, Gene wrote:

I've seen many times in JAWS when the buffer does not refresh when the screen refreshes and you see old information.  I have to use the screen refresh command in JAWS, JAWS key escape, when that occurs.  At times, such as when filling out a form, if I refreshed the page, I would lose information I entered.  If this ever happens in NVDA, I have seldom, if ever seen it happen but it appears that NVDA key f5 does the same thing as the JAWS command, refreshes the buffer browse mode uses.

This is a proper function of a screen-reader because the problem is in the screen-reader and it is not desirable to refresh the actual page.

Gene

On 7/12/2022 10:46 AM, Brian Vogel wrote:
Dave,

No problem.   I'm still at a bit of a loss to even understand what all the hubbub is about.  This sort of thing does happen, if not constantly, then at least often enough that we all encounter it.

I've never seen an instance where using the browser's own reload current page button doesn't get things right back to where they need to be (whether a screen reader is part of the mix or not).  That's why that function exists in every browser I've ever used.  It's not a screen reader function, per se, nor should it be.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill



Gene
 

We are talking about different things.  Many of Joseph Lee's comments are beyond my technical knowledge.  I don't know if rereading parts of the message would make it clear to me but there were a number of statements I didn't understand.

But you appear to be talking about a page that is coded to refresh in the browser or a part of a page, such as a stock ticker.  The original question was whether there is a screen refresh command in NVDA.  That is what I am discussing, not a page that automatically refreshes, but a page that loads and doesn't refresh. 

I have seen instances in JAWS when I am filling out a form or changing a combo box and the new information or setting is not reflected when I return to the Virtual PC cursor.  Using the JAWS refresh command causes the change to be shown.

Gene

On 7/12/2022 11:37 AM, Dave Grossoehme wrote:

Hi:  No it isn't just in the one application.  As Joseph explained in his message within the last 24 hours, it's in the communication of the browser and the screen reader and the API that are making the communications between the web site and the browser and the screen reader.  As Bryan said in an earlier message it also depends on the language used for the web page as to whether it will refresh or not. 

Dave


On 7/12/2022 12:32 PM, Gene wrote:
I've seen many times in JAWS when the buffer does not refresh when the screen refreshes and you see old information.  I have to use the screen refresh command in JAWS, JAWS key escape, when that occurs.  At times, such as when filling out a form, if I refreshed the page, I would lose information I entered.  If this ever happens in NVDA, I have seldom, if ever seen it happen but it appears that NVDA key f5 does the same thing as the JAWS command, refreshes the buffer browse mode uses.

This is a proper function of a screen-reader because the problem is in the screen-reader and it is not desirable to refresh the actual page.

Gene

On 7/12/2022 10:46 AM, Brian Vogel wrote:
Dave,

No problem.   I'm still at a bit of a loss to even understand what all the hubbub is about.  This sort of thing does happen, if not constantly, then at least often enough that we all encounter it.

I've never seen an instance where using the browser's own reload current page button doesn't get things right back to where they need to be (whether a screen reader is part of the mix or not).  That's why that function exists in every browser I've ever used.  It's not a screen reader function, per se, nor should it be.
--

Brian - Windows 10, 64-Bit, Version 21H2, Build 19044  

The real art of conversation is not only to say the right thing in the right place but to leave unsaid the wrong thing at the tempting moment.

        ~ Dorothy Nevill