Re: lynx word bleeding?

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