<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 01/11/2012 11:42 AM, Frederik Gladhorn wrote:
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<blockquote type="cite">
<pre wrap="">On 01/10/2012 04:46 PM, Frederik Gladhorn wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Initial suggestions for apps to get rocking with a11y were Kate and
KMail by the way.
</pre>
</blockquote>
<pre wrap="">
Back then I added a QAccessibleInterface to Kate to implement focus
tracking. I think what is needed to improve that is a
consumer-application similar to what I started back then with
KAccessible1. Also I would really like to add Konsole to that mix. imho
it should have the highest priority among the consumer applications to
get proper a11y done for Konsole.
In detail I would suggest in no particular order;
* QAccessible interface's for Konsole to implement focus tracking there.
</pre>
</blockquote>
<pre wrap="">
Do you think we need a new interface in Qt or will the current text interfaces
suffice? I have not spent any time thinking what it takes to make the shell
accessible.
</pre>
</blockquote>
<br>
I think QAccessible has everything we need for Konsole. In Kate it
was done that way; A parent QAcessibleInterface that repsresents the
canvas and a child QAcessibleInterface for the cursor. Then the
common x/y/width/height attributes are used to inform others about
the canvas/cursor-positions/dimensions making it possible to e.g.
follow the cursor when the KWin zooming plugin is active aka
enabling focus tracking.<br>
<br>
I think we should do something similar for Konsole. QAcessible has
everything we need. The problem is when it comes to bridging
QAccessible<=>atspi cause iirc atspi does that different by
defining an own "TextCursor dbus interface". I think we should
definitivly not expose such design-mistakes[1] to QAccessible but
solve that in qtatspi by e.g. creating transparent a parent
interface with a cursor child interface.<br>
<br>
[1] Lot of additional code in consumers needed to handle special
cases where it would not be needed. Other cursors then text-cursors
are completely left out. Well, I like QAcessibles way to use just an
own caret object way more then specializations.<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">Checking with the gnome terminal, it seems to mostly implement the text
interface which should not be a big deal.
</pre>
</blockquote>
<br>
For Konsole I was thinking of something like;<br>
<br>
top-level (well, under MainWindow which has e.g. the mainmenu);<br>
* <span class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;">QAccessible::Document
(and/or </span></span><span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0);
font-family: Arial; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;
word-spacing: 6px;">QAccessible::List/</span></span><span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;">QAccessible::PageTab/</span></span><span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;">QAccessible::PageTabList</span></span><span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;"> to represent</span></span><span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;"> the
different shells. One instance per tab)<br>
<br>
direct children of the document;<br>
</span></span>* <span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0);
font-family: Arial; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;
word-spacing: 6px;">QAccessible::EditableText (the current
input-line)<br>
</span></span>* <span class="Apple-style-span"
style="border-collapse: separate; color: rgb(0, 0, 0);
font-family: Arial; font-style: normal; font-variant: normal;
font-weight: normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-indent: 0px; text-transform: none; white-space:
normal; widows: 2; word-spacing: 0px; font-size: medium;"><span
class="Apple-style-span" style="font-family: monospace;
word-spacing: 6px;">Q</span></span><span
class="Apple-style-span" style="border-collapse: separate; color:
rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;">QAccessible::Caret
(the text-cursor within the canvas)</span></span><br>
* <span class="Apple-style-span" style="border-collapse: separate;
color: rgb(0, 0, 0); font-family: Arial; font-style: normal;
font-variant: normal; font-weight: normal; letter-spacing: normal;
line-height: normal; orphans: 2; text-indent: 0px; text-transform:
none; white-space: normal; widows: 2; word-spacing: 0px;
font-size: medium;"><span class="Apple-style-span"
style="font-family: monospace; word-spacing: 6px;">QAccessible::StaticText
(the output of the last command - probably as List for history
or just an additional List that keeps all of the history
independent of whatever the last feedback was)</span></span><br>
<br>
There may some more things like e.g. QAccessible actions to
copy+paste into the comand-line or from the feedback. <br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<blockquote type="cite">
<pre wrap="">* Write KAccessible2 as successor of KAccessible1. The first version is
based on QAccessible direct while what we like to have is a KDE-client
that uses at-spi. Yes, an Orca "replacement" that would a) integrate
into the desktop and b) make Gtk-applications accessible under KDE too
and c) act as lib/daemon for consumers like the KWin Zoom plugin and
KMagnifier.
More detailed KAccessible2 should implement following features;
1) focus-tracking
2) screen-reader
2b) keyboard-echo
3) display of the a11y "widget" hierarchy of an application and
on-screen marking of the boundaries of selected "widgets" (note that in
that context widget means a11y-object). That is useful cause it will on
the one hand get the code in place to proper inspect applications and to
navigate through them on the other hand.
4) braile
The first two points are done in KAccessible1. 2b, 3 and 4 are new features.
</pre>
</blockquote>
<pre wrap="">
Lots of points there ;)
This I'm not so sure about.
The Gnome people are currently trying to untangle screen magnifier and orca.</pre>
</blockquote>
<br>
The screen-magnifier in Orca is deprecated to my knowledge and
cannot be reused [2]. The Gnome Shell has an own new magnifier what
is exactly what we have in our KWin zooming plugin except our plugin
is more user-friendly :-)<br>
<br>
I think what we need do is to change the *one* line in the
zooming-plugin and the *one* line in KMagnifier to use qtatspi
rather then dbus direct to connect with a signal that gives the
x/y-position of the focus when the focus changes. The question is
how complicated is it in atspi2 to connect with that signal? From my
memories back then I was serious scared how much code in Orca was
needed to implement such simple things. We definitivly should try to
avoid to push such pain to consumers of atspi2 (means
KMagnifier/KWin zooming plugin/screen-reader/etc/pp).<br>
<br>
[2] my knowledge here is 1-2 years old so maybe outdated but then I
would be very surprised if so. If you, dear reader, has more details
please post them *now*<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">It
should be separate IMHO, just working well together.
I wrote the basics for Qt based clients against at-spi dbus. It currently sits
on my machine. I will have to clean that up at some point.
1) and 2) belong together into one imho. 2b) also.
</pre>
</blockquote>
<br>
yay, I am very keen to see that code. Release early, release often!
:-)<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">3) currently we have accerciser as developer tool. It's not perfect but I
don't think it's that important to get another tool like that at the moment.
</pre>
</blockquote>
<br>
I think inspecting the a11y-structure of an applications is a very
basic requirement. But yes, it may not have that super-important
priority like other things may have :)<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">I'd rather see accerciser improved in a few places.
</pre>
</blockquote>
<br>
Accerciser is neither integrated in the KDE-desktop nor can the code
be reused :-/ I think those both are killer-arguments. Especially
with such a basic functionality you need to have reusable code imho.
Note that with reusable I mean a lib that provides a high-level API
(e.g. a QAbstractItemModel) for that so consumers do not need to
reinvent and duplicate such functionality again and again.<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">4) Yes, absolutely. I have no knowledge about braile. If anyone can help, step
up. But in my opinion this is a next step after getting the basics in place.
</pre>
<blockquote type="cite">
<pre wrap="">* Adapt focus-tracking in KMagnifier and the KWin Zoom plugins to use
KAccessible2 rather then KAccessible1.
</pre>
</blockquote>
<pre wrap="">
Hm, I would want a generic qt-at-spi-client lib that can be used for this, I
think.
</pre>
</blockquote>
<br>
Definitive.<br>
+32767<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">On 01/10/2012 12:25 AM, Frederik Gladhorn wrote:
</pre>
<blockquote type="cite">
<pre wrap="">And we have great stuff such as Simon which is the awesome and just
needs a bit of polish to make me want to use it for fun and coolnes
despite being able to use mouse and keyboard.
</pre>
</blockquote>
</blockquote>
<pre wrap="">Simon should definitivly get some gsoc slots :)
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">For going all in: remember we will not have Plasma accessible any time
soon. I'm currently working on QML a11y in Qt 5. While technically
doable I don't see myself doing work on QGraphicsView in this area.
</pre>
</blockquote>
</blockquote>
<pre wrap="">* Add/Improve Plasma a11y. Focus on Panel, Desktop, Folderview, Kickoff,
KRunner. That should be a good start.
</pre>
</blockquote>
<pre wrap="">
Yes. Is anyone going to hack something up? I guess it would be possible, I
don't have the time. Maybe you are right though and we can "fake" it
circumventing graphicsview and just focusing on this part.
</pre>
</blockquote>
<br>
I think we would probably only need a very high level here to be
able to navigate through running applications/windows (yes, not
really related to Plasma but then maybe we like to take e.g.
activities into account?), through the available applications (may
it be with a kickoff QAccessibleInterface or an own "QAccessible
app-luncher" and through other probably important things (e.g.
file-copy progress, errors/notifications, etc).<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">So who's going to do the work? I think these are all great plans and we are
getting a clearer picture, but now we need someone to get their hands dirty ;)
</pre>
</blockquote>
<br>
Well, the gsoc students :-)<br>
<br>
<blockquote cite="mid:21393821.tt6qyLoToL@varney" type="cite">
<pre wrap="">I'd love to do some of these but I am busy fixing up Qt accessibility in
general. I do want to help/mentor whoever feels like doing something very
worthwile though ;) And of course Sebastian did great work, so I hope you
continue with that.
</pre>
</blockquote>
<br>
Unfortunately my spare time is very limited this days too. But I
could probably mentor some student who would put time, energy and
love into KDE-a11y.<br>
<br>
In any case collecting those ideas and todo's and brainstorming
cannot harm.<br>
<br>
</body>
</html>