This is almost certainly a contingency or conflict issue. You
get them when two or more processes are trying to grab the same
resource. I am speaking in general terms because I do not have
the slightest idea whether we are dealing with a keyboard
interrupt or what but that's what a contingency issue looks or
sounds like.

	The screen readers for Windows probably install a full
keyboard handler routine to make all the keyboard commands for
the screen reader work and then what's left over gets passed on
to the rest of the system for normal use. I would imagine that
mouse movements get simulated and stuffed in somewhere and a lot
of cool stuff happens behind the scenes to make the rest of your
system feel like you have a mouse and are a normal Windows user
even though you are running JAWS or NVBA or Window-eyes. It
almost has to be that way to work at all.
Since screen readers in Windows and DOS have to monkey with the
system at a very low level, other software can easily step all
over what the screen reader had to do and change the order of
events or reset address vectors that the screen reader needed to
work a certain way and that's how we get some of the weirdness
such as the eaten first character that gets echoed but never
stored.

	One interesting experiment you might try is to strike a
key that normally does nothing by itself such as shift or Alt
and then release it before you type that first character and see
if that changes anything. If it makes it work, good. If not,
back to the drawing board.

Martin