[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-accessibility
Subject: Fwd: Re: [orca-list] Kate editor accessibility
From: chrys <chrys () linux-a11y ! org>
Date: 2018-11-01 12:49:26
Message-ID: db334ee7-24bc-34a7-ff89-59c69b74afd0 () linux-a11y ! org
[Download RAW message or body]
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 <jdiggs@igalia.com>
An: chrys <chrys@linux-a11y.org>
Kopie (CC): orca-list <orca-list@gnome.org>
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
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Howdy list,</p>
<p>Joanie investigated the Kate issues for us. ill forward the
results here.</p>
<p>maybe we can see what we can do. <br>
</p>
<p>cheers chrys<br>
</p>
<div class="moz-forward-container"><br>
<br>
-------- Weitergeleitete Nachricht --------
<table class="moz-email-headers-table" cellspacing="0"
cellpadding="0" border="0">
<tbody>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Betreff:
</th>
<td>Re: [orca-list] Kate editor accessibility</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Datum: </th>
<td>Thu, 1 Nov 2018 12:35:22 +0100</td>
</tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Von: </th>
<td>Joanmarie Diggs <a class="moz-txt-link-rfc2396E" \
href="mailto:jdiggs@igalia.com"><jdiggs@igalia.com></a></td> </tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">An: </th>
<td>chrys <a class="moz-txt-link-rfc2396E" \
href="mailto:chrys@linux-a11y.org"><chrys@linux-a11y.org></a></td> </tr>
<tr>
<th valign="BASELINE" nowrap="nowrap" align="RIGHT">Kopie
(CC): </th>
<td>orca-list <a class="moz-txt-link-rfc2396E" \
href="mailto:orca-list@gnome.org"><orca-list@gnome.org></a></td> </tr>
</tbody>
</table>
<br>
<br>
Hey Chrys.<br>
<br>
In answer to your questions:<br>
<br>
On 10/31/18 11:02 PM, chrys wrote:<br>
<br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<br>
When you use the arrow keys to move by line, Orca asks AT-SPI2 for
the<br>
line at offset. When I ask for a line of text, Kate responds with
all<br>
the text typed until I pressed Enter (i.e. a hard return) What
Kate<br>
should instead respond with is all the text on the visual line,
which<br>
ends at the point the text wrapped due to the window size. Make
sense?<br>
<br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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).
</pre>
</blockquote>
<br>
It looks like Kate is not telling us about key presses and key
releases;<br>
only key releases. What we see from Gtk+, Gecko, etc. is an
ordering<br>
like this:<br>
<br>
Action 1:<br>
Key press down<br>
Caret moves one line down<br>
Key release down<br>
<br>
Action 2:<br>
Key press right<br>
Caret move one char to the right<br>
Key release right<br>
<br>
Action 3:<br>
Key press right<br>
Caret move one char to the right<br>
Key release right<br>
<br>
What we're getting from Kate seems to be:<br>
<br>
Action 1:<br>
Caret moves one line down<br>
Key release down<br>
<br>
Action 2:<br>
Caret move one char to the right<br>
Key release right<br>
<br>
Action 3:<br>
Caret move one char to the right<br>
Key release right<br>
<br>
Orca uses a combination of the caret-moved events and the keyboard<br>
events to try to figure out what the user is doing and, based on
that,<br>
figure out what to present. This combination is needed because a<br>
keyboard event doesn't necessarily result in the caret moving, and<br>
caret-moved events don't tell you why the move occurred; merely
that the<br>
caret is at a new location.<br>
<br>
So when a caret moved event comes in, Orca looks at the last key
event<br>
and determines what to present to you. In the Gtk+, Gecko, etc.<br>
scenario, we know what arrow key you pressed before the caret
moves so<br>
we can guess correctly whether or not to present a line versus a<br>
character. But Kate isn't telling us about key presses. So the
last key<br>
isn't what you just did; it's what you did one step back. It's
only<br>
after Orca presents the new caret's location that it is told what
arrow<br>
key you pressed.<br>
<br>
There may be some sort of hack I can add in Orca to work around
this<br>
issue. But the lack of key press events is a bug in Kate (or Qt or<br>
whatever). And if they fix that bug, I believe Orca will start
doing the<br>
right thing automatically. Plus the more hacky guesswork I have to
add<br>
to Orca, the less reliable Orca will be. So do you think you can
get<br>
this fixed in Kate (or Qt or whatever)?<br>
<br>
--joanie<br>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic