GNOME.org
 

[orca-list] KDE accessibility update: looks like they need some help

Hi, list,

Please see forwarded message below fromt he kde accessibility list.

Thanks.
Alex M

---------- Forwarded message ----------
From: kde-accessibility-request kde org
Date: Thu, 12 Jan 2012 12:00:23 +0000
Subject: kde-accessibility Digest, Vol 97, Issue 5
To: kde-accessibility kde org

----------------------------------------------------------------------

Message: 1
Date: Wed, 11 Jan 2012 14:11:36 +0100
From: Sebastian Sauer <mail dipe org>
To: Frederik Gladhorn <gladhorn kde org>
Cc: kde-soc-mentor kde org, kde-accessibility kde org
Subject: Re: [Kde-accessibility] focusing on accessibility
Message-ID: <4F0D8A88 20200 dipe org>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"

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

------------------------------

_______________________________________________
kde-accessibility mailing list
kde-accessibility kde org
https://mail.kde.org/mailman/listinfo/kde-accessibility


End of kde-accessibility Digest, Vol 97, Issue 5
************************************************
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]