Fwd: Re: [orca-list] Kate editor accessibility

Howdy list,

Joanie investigated the Kate issues for us. ill forward the results here.

maybe we can see what we can do.

cheers chrys



-------- Weitergeleitete Nachricht --------
Betreff: 	Re: [orca-list] Kate editor accessibility
Datum: 	Thu, 1 Nov 2018 12:35:22 +0100
Von: 	Joanmarie Diggs <[email protected]>
An: 	chrys <[email protected]>
Kopie (CC): 	orca-list <[email protected]>



Hey Chrys.

In answer to your questions:

On 10/31/18 11:02 PM, chrys wrote:

> Bug 1: Arrow up/ down will not interrupt orcas current speech output.
> maybe it looks like to additional content to orca instead of an line
> navigation. So ctrl needs to been pressed after every line change to
> interrupt speech. can you check why orca is not interrupting here on
> line change.

When you use the arrow keys to move by line, Orca asks AT-SPI2 for the
line at offset. When I ask for a line of text, Kate responds with all
the text typed until I pressed Enter (i.e. a hard return) What Kate
should instead respond with is all the text on the visual line, which
ends at the point the text wrapped due to the window size. Make sense?

> Bug 2. After doing arrow up / down start to navigate by char (arrow left
> / right) orca does repeat the previous line once instead of just speak
> the char. this only happen once and directly after an line navigation
> (arrow up/ down).

It looks like Kate is not telling us about key presses and key releases;
only key releases. What we see from Gtk+, Gecko, etc. is an ordering
like this:

Action 1:
Key press down
Caret moves one line down
Key release down

Action 2:
Key press right
Caret move one char to the right
Key release right

Action 3:
Key press right
Caret move one char to the right
Key release right

What we're getting from Kate seems to be:

Action 1:
Caret moves one line down
Key release down

Action 2:
Caret move one char to the right
Key release right

Action 3:
Caret move one char to the right
Key release right

Orca uses a combination of the caret-moved events and the keyboard
events to try to figure out what the user is doing and, based on that,
figure out what to present. This combination is needed because a
keyboard event doesn't necessarily result in the caret moving, and
caret-moved events don't tell you why the move occurred; merely that the
caret is at a new location.

So when a caret moved event comes in, Orca looks at the last key event
and determines what to present to you. In the Gtk+, Gecko, etc.
scenario, we know what arrow key you pressed before the caret moves so
we can guess correctly whether or not to present a line versus a
character. But Kate isn't telling us about key presses. So the last key
isn't what you just did; it's what you did one step back. It's only
after Orca presents the new caret's location that it is told what arrow
key you pressed.

There may be some sort of hack I can add in Orca to work around this
issue. But the lack of key press events is a bug in Kate (or Qt or
whatever). And if they fix that bug, I believe Orca will start doing the
right thing automatically. Plus the more hacky guesswork I have to add
to Orca, the less reliable Orca will be. So do you think you can get
this fixed in Kate (or Qt or whatever)?

--joanie