[Kde-accessibility] On Qt accessibility and a on-screen keyboard. (Klavi[atura])

[Gunnar Schmi Dt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

> > [...]
> > However, I would say that it might be easier for an assistive technology
> > to always use methods from QAccessibleInterface. In that way you would
> > not
>
> Yeah, I tried it (commited), and it did kind of help reduce code size. But
> unfortunately, widgets are still not without quirks -- i.e. the popups
> encode their accel (i.e. the ctrl-foo one, not the underscore) one in their
> Name.
>
If the popups encode their keyboard shortcut in their name, that is definitely 
a bug in the accessibility implementation of the popup, not in your code. 
Adding special code for a work-around sounds wrong to me.

> > need special code for menu bars etc. Off course that implies that each
> > menu item would support actions like show() (if it has a sub menu) and
> > activate().
>
> They're the same action.
>
Sure, in menu bars both of them are the default actions (as either the one or 
the other is available). In tool bars they are not necessarily the same: On 
toolbar buttons for delayed popup menus they are two different actions.

> > The point is not that it is "wrong" to use explicit knowledge, but it is
> > impossible to know all the widgets that might exist in Kde or Qt based
> > applications. The only way for third party applications to make their
> > widgets fully accessible is to create a subclass of QAccessibleInterface
> > for their widgets. This means that QAccessibleInterface needs to contain
> > all needed functionality.
>
> I am quite aware of this. However, sometimes things aren't perfect, and one
> has to deal with 99.9% solutions. Oh, and it's not necessary for
> QAccessibleInterface to contain *absolutely* everything -- many things can
> be done generically with plain QWidget.
>
Sure, if the GUI element is based on QWidget. However, there are GUI elements 
that are not based on QWidget. For example entries in a QTable, in a 
QListView or in a QListBox are not even based on QObject :-(

> > [...]
> > Maybe we do have a misunderstanding here. Of course assistive
> > technologies need an API other than QAccessibleInterface. What I wanted
> > to say is that the typical KDE application programmer (i.e., someone who
> > writes for example an accessible game) does only need to know about
> > QAccessibleInterface.
>
> Ahh, I see, but I think even that is extreme. The typical application
> programmer should simply use standard widgets.
> [...]
True, the easiest way it to use standard widgets. However, many typical 
applications have a custom widget for the drawing area. For this widget the 
application programmer might want to add an accessibility implementation. 

However, providing a special accessibility plug in for only one widget sounds 
like too much overhead to me. I hope that we are able to add support for 
custom accessibility implementations without the need for a new accessible 
plug in. The QAccessibleInterface class is not avoidable, though.

> > > Yes. When a popup menu is up, it does a global keyboard mouse grab.
> > > That means all mouse clicks go to the popup (it has something to do
> > > with race conditions, remember X is asycnhrous).
> > > [...]
> >
> > Hm, I'm not sure how to solve this. It is a problem with your specific
> > assistive technology, so solving this in every single application does
> > not look right to me. I think it is a general problem that also happens
> > to other toolkits. For demonstration purposes it might be ok if we just
> > live with the mouse grab.
>
> You can't interact with a visible popup then. gok seems to deal with this
> (which I could try out a little bit thanks to Peter Korn's hints -- thanks)
> by just not showing the widgets. This does save real-estate, but seems kind
> of weird, since you can never quite match the 'native' representation in an
> on- screen keyboard; and of course many people who can't use 'regular'
> input device can have perfect vision.

Not showing the popup is no solution. However, assistive technologies like 
screen readers should be able to deal with mouse grabs as they work in the 
background. On-screen keyboards may be able to deal with mouse grabs, too, if 
the input method for them is based on anything other than mouse clicks or 
keyboard.

The only place where the problem shows is if an assistive technology needs to 
be accessed by the mouse or the keyboard. For these ATs it is important for 
interoperability reasons to have a Unix-wide solution. Maybe we need to add 
support for that to our infrastructure (and to both ATK and AT-SPI, too, if 
they don't support it).

Gunnar Schmi Dt
- -- 
Co-maintainer of the KDE Accessibility Project
Maintainer of the kdeaccessibility package
http://accessibility.kde.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/C/GusxZ93p+gHn4RAoG5AJ0bkj4gBsKFkTMub8rL9g1821v3wgCfe0Ra
y1N3/JQhJ0C4lM0vNNYFVMg=
=PpsO
-----END PGP SIGNATURE-----