[Kde-accessibility] focusing on accessibility

Wed Jan 11 13:11:36 UTC 2012

On 01/11/2012 11:42 AM, Frederik Gladhorn wrote:
>> On 01/10/2012 04:46 PM, Frederik Gladhorn wrote:
>>> Initial suggestions for apps to get rocking with a11y were Kate and
>>> KMail by the way.
>> 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.
> 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.

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.

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.

[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.

> Checking with the gnome terminal, it seems to mostly implement the text
> interface which should not be a big deal.

For Konsole I was thinking of something like;

top-level (well, under MainWindow which has e.g. the mainmenu);
* QAccessible::Document (and/or 
QAccessible::List/QAccessible::PageTab/QAccessible::PageTabListto 
representthe different shells. One instance per tab)

direct children of the document;
* QAccessible::EditableText (the current input-line)
* QQAccessible::Caret (the text-cursor within the canvas)
* 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)

There may some more things like e.g. QAccessible actions to copy+paste 
into the comand-line or from the feedback.

>> * 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.
> Lots of points there ;)
> This I'm not so sure about.
> The Gnome people are currently trying to untangle screen magnifier and orca.

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 :-)

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).

[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*

> 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.

yay, I am very keen to see that code. Release early, release often! :-)

> 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.

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 :)

> I'd rather see accerciser improved in a few places.

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.

> 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.
>
>
>> * Adapt focus-tracking in KMagnifier and the KWin Zoom plugins to use
>> KAccessible2 rather then KAccessible1.
> Hm, I would want a generic qt-at-spi-client lib that can be used for this, I
> think.

Definitive.
+32767

>>> On 01/10/2012 12:25 AM, Frederik Gladhorn wrote:
>>>> 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.
>> Simon should definitivly get some gsoc slots :)
>>
>>>> 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.
>> * Add/Improve Plasma a11y. Focus on Panel, Desktop, Folderview, Kickoff,
>> KRunner. That should be a good start.
> 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.

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).

> 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 ;)

Well, the gsoc students :-)

> 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.

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.

In any case collecting those ideas and todo's and brainstorming cannot harm.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-accessibility/attachments/20120111/7b2bde33/attachment.html>