Honestly?
Well I must have an advantage using a DOS screen reading program arctic
business vision to come here, as I have never encountered the slight
character overlay I am getting now, and it does not show up everywhere
either.
the control-l solution is working fine though on those few moments.
Have never encountered the page problem one until this particular DOS
computer which is much faster than any I have used previously with a
faster processor and almost a gig of memory. In my personal case
it is not that characters from the next page blend, but that words from
the prior page remain, which may be a buffer thing as I sometimes have to
pull on the reigns a bit.
otherwise I miss part of a page.
shows that quality detailed screen readers created for lower graphics
environments like the shell ones, may have an advantage.
the gmail thing for me did not mirror the one shared by mouse.
Last December google accessibility circulated a direct to basic html
option which I have bookmarked.
In fact the old one still works for me too, at least with my main gmail
account.
Karen
On Sun, 30 Jan 2022, Luke at Shellworld Support wrote:
On Fri, 28 Jan 2022, Karen Lewellen wrote:
previously as in for all the years I have used lynx, if I move to another
page, the contents of that page is all I hear.
Now though I am getting bleed over from the previous page, in some spots, as
if the content is still there.
its honestly weird, because it has never happened before, ever.
What's interesting, is that this has never happened to you before. It has
been happening to me for about 15 years, maybe more, in lynx. It
especially happens with remote connections (such as one to shellworld),
and not so much when using lynx on a local linux console.
The Control+L solution from Thorsten and Travis, to redraw the screen, is
pretty much the only way to deal with this if it's happening, unless you
can play with terminal emulation to fix it.
There is a secondary effect that happens with screen reading and lynx (or
really anything ncurses based): dropped/added letters/words.
This happens, as best as I can tell, when you press space to advance a
page, and some of the character positions on the next page, have the same
letters/words in them as were on the previous page.
In that case, Ncurses doesn't bother re-drawing those locations with the
new data, which would be the same as the old data. At least, that's what I
think is happening.
The screen reader, however, is only reading new data, so skips the
non-redrawn content, resulting in weird speech.
As a result of that one, which is far more common for me than the first
one, I now nearly always hit my "read screen" command, every time I move
to the next page. That causes the screen reader to start at the top, and
process the screen as if it was completely new.
Maybe a bit harder to do if you're using Windows terminal emulation, where
"the screen" is a somewhat different concept.
Alternatively, Control+L solves that one as well, since then every
character is re-drawn. Although screen readers, at least some of them, may
run into buffering issues if having a full page thrown at them in
character mode, so I don't recommend Control+L for either problem, without
also using a subsequent read screen or other reading command. In other
words, let the re-draw finish before trying to process it with speech,
don't rely on the re-draw to feed the speech.
Luke
