[Kde-accessibility] On Qt accessibility and a on-screen
Gunnar Schmi Dt
gunnar at schmi-dt.de
Wed Jul 9 13:42:48 CEST 2003
-----BEGIN PGP SIGNED MESSAGE-----
> > [...]
> > 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
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the kde-accessibility