toggle quoted message
Show quoted text
I didn't either, but that didn't stop me from doing it.
Like I stated it depends on the web page code if they allow it or
On 7/13/2022 11:18 AM, Gene wrote:
I was talking about a web page opening, as in downloading a web
page. You are evidently talking about downloading a file. I
haven't seen any information about whether Edge can resume
On 7/13/2022 8:48 AM, tim wrote:
Now with edge I have restarted some downloads.
You have to use control + j and arrow down to the download.
Now hit application or shift + f10 and arrow down to resume
if it shows. That depends on the sites coding.
On 7/12/2022 11:15 AM, Gene wrote:
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.
On 7/12/2022 10:06 AM, Dave
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
On 7/10/2022 11:41 AM, Joseph
[Edited Message Follows]
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
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:
- User (to web browser): I want to browse to a
- Browser (to user, after a pause): okay, here is the
document you have requested.
- NVDA (to web browser): but wait, the user is blind,
so I need a way to present the document in a suitable
- Web browser (to NVDA): what do you want me to do for
- 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.
- 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)?
- NVDA messenger (to web browser): here I am, give me
the raw document content please.
- Web browser (to NVDA messenger, after gathering the
raw document content in a suitable form): here it is.
- NVDA messenger (to NVDA): okay, I did what you've
- NVDA (to NVDA messenger): well done, I will tell my
user about it.
- NVDA (to user): Loading document...
- NVDA (to user, after the document is formatted):
here it is (then starts reading from the top if the
user says so).
- 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.