Re: interacting with the cursor:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



ok,  a claim has been made that the windows screen readers fudge reality on 
this point.  The claim is that in the real world of windows, the ehavior you 
get for instance with backspace or delete depends on which side of the 
character you are sitting on.  In the three screen readers I know of, this 
behavior is not present.  If I hear that I am sitting on a character, that 
is the character I interact with when I hit delete or backspace and if I 
type, that character is pushed to the right.  Now, you say that the at does 
not fudge this but why then in earlier screen readers was it present and 
then it disappeared later in dos?  I'm not denying what you say, ut I want a 
clear idea of what you are actually saying.

-- 
Johnnie Apple Seed
----- Original Message ----- 
From: "Janina Sajka" <janina@xxxxxxxxxxx>
To: "Linux for blind general discussion" <blinux-list@xxxxxxxxxx>
Sent: Wednesday, March 30, 2005 12:53 AM
Subject: Re: interacting with the cursor:


I think you're making it more complicated than it is. When Speakup
tracks the cursor, it's nothing whatsoever about backspace, delete or
insert. It's about one thing, and one thing only, where will the next
char typed be placed. On screen with the visual cursor it's perhaps
clearer because the cursor goes between two chars, thus indicating where
the next typed char will be placed. Thus the dictionary can define
cursor as an "insertion point." Ironically, this tends to turn the
insert key into what might better be called the "overstrike" key.

I suppose we could do that with screen readers, too, but we don't.
There's really no reason we must have a "current char" with screen
readers.Of course, it becomes useful to think of a "current char" when
reading, as opposed to writing. We like to be able to say "We're right
here."

Looking at this a bit further, it's even more specific to applications.
For example, in vim one chooses whether to begin adding chars ahead of
the current char, or after it. The command to go to insert mode is i for
the former and a for the latter. But that's still not about the screen
reader. It's all about the application and its environment.

david poehlman writes:
> Kenny and all,
>
> The cursor is never on a character as I understand it but the screen 
> readers
> have tweaked the ui or the screen readers have a ui that defines the
> behavior as if the cursor were a block covering a character that you hear.
> When you say that gnoernicus tracks the cursor, in what ehavior with 
> regard
> to ackspace, delete and insert does this produce?
>
> -- 
> Johnnie Apple Seed
> ----- Original Message ----- 
> From: "Kenny Hitt" <kenny@xxxxxxxxxxxxx>
> To: "Linux for blind general discussion" <blinux-list@xxxxxxxxxx>
> Sent: Tuesday, March 29, 2005 10:03 PM
> Subject: Re: interacting with the cursor:
>
>
> Hi.  Your description is a little confusing, but I think the answer to
> your question is yes.
>
> You move the cursor to the right of the char to delete if you use
> backspace, and you put the cursor on the char to delete if you use the
> del key.  Usually, the screen reader reads the char under the cursor
> when you use the "read current char" function of the screen reader.
>
> As far as I know, Gnopernicus doesnt have a "read current char" key, but
> it tracks the cursor.
>
> Hope this helps.
>           Kenny
>
> On Tue, Mar 29, 2005 at 09:26:53PM -0500, david poehlman wrote:
> > Hi all,
> >
> > Sorry if this appears twice, I sent it out from the rong address.
> >
> > I have a question for users of graphical and non graphical linux users
> > concerning its screen reader behavior regarding cursor interaction.  In
> > windows screen readers and in dos screen readers with the accetion of 
> > some
> > older dos screen readers, when interacting with the cursor, the screen
> > reader interacts with the character that is heard when a say character
> > request is sent.  In other words, if I am told by say character that I 
> > am
> > sitting on t and I hit backspace or delete, t is gone.  If I type, t is
> > pushed to the right as I type.  If I move to the left of t and type, the
> > character to the left of t is pushed to the right.  If I move to the 
> > right
> > of t and type, the character to the right of t is pushed to the right as 
> > I
> > type.  My question then is whether this is the behavior in all flavors 
> > of
> > linux with screen readers and if not, how do the ones that differ 
> > behave?
> > In windows, the cursor is a thin vertical line which is never on a
> > character
> > but always between characters or to the left of the character or to the
> > right of the character.  The net effect would then be that if one were 
> > to
> > want to delete a character with back space, one would have to be certain
> > to
> > be to the right of the character to be deleted and if one wanted to use
> > delete to delete a character, one would need to be the left of the
> > character
> > to be deleted.
> >
> > Answers and discussion would be greatly appreciated.  Should windows
> > screen
> > readers or linux screen readers adopt this strategy if they don't employ
> > it
> > already?  Are their better strategies than those described above and if
> > so,
> > what are they?
> >
> > It might be that the later strategy would be closer to the sighted
> > experience.
> >
> > -- 
> > Johnnie Apple Seed
> >
> > _______________________________________________
> > 
> > Blinux-list@xxxxxxxxxx
> > https://www.redhat.com/mailman/listinfo/blinux-list
>
> _______________________________________________
> 
> Blinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/blinux-list
>
> _______________________________________________
> 
> Blinux-list@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/blinux-list

-- 

Janina Sajka Phone: +1.202.494.7040
Partner, Capital Accessibility LLC http://www.CapitalAccessibility.Com

Chair, Accessibility Workgroup Free Standards Group (FSG)
janina@xxxxxxxxxxxxxxxxx http://a11y.org

If Linux can't solve your computing problem, you need a different problem.

_______________________________________________

Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list

_______________________________________________

Blinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/blinux-list

[Index of Archives]     [Linux Speakup]     [Fedora]     [Linux Kernel]     [Yosemite News]     [Big List of Linux Books]