[Kde-accessibility] Timeframe for KDE 4

Olaf Jan Schmidt ojschmidt at kde.org
Tue Feb 21 11:36:24 CET 2006


[ Gary Cramblitt ]
> I believe there is ALOT more to this.  The AT-SPI currently requires CORBA
> libraries.  There is a desire to switch it to DBUS. To do this properly, 
> we need an IDL to DBUS compiler.  AFAIK, nobody has begun work on that. 

Harald said someone is working on it (I don't remember who), but I agree that 
this needs to be added to our list of requirements for KDE4.

There are two parts to AT-SPI support in KDE. One of the parts (making KDE 
applications accessible to assistive technologies) would be possible without 
a move to DBUS. The other part (making the KDE assistive technologies support 
AT-SPI) needs DBUS.

> Some of the focus problems mentioned there might actually be problems with
> themes.  The KDE default Plastik theme highlights by painting a blue
> background that obscures the focus rectangle.  Change to a different theme,
> or change the color, and you can see the focus rectangle.

Thanks for the observation. I nevertheless think that the code for the focus 
rectangle should be updated to work with more colour schemes. My current idea 
is to add focus colours to the colour schemes (for focus rectangles and 
mouse-over effects).

>   1.  Toolbars cannot be navigated without a mouse.

The position of Gnome and Windows is that toolbars do not need keyboard 
support if the functionality is also available elsewhere, but MacOS indeed 
has a keyboard navigation mode for toolbars.

>   2.  QSplitter and QDockWindow, and the widgets derived from them cannot
> be sized, undocked, or docked without a mouse.  See
> trunk/koffice/lib/kofficecore/kkbdaccessextensions.h/cpp for the KOffice
> 1.5 kludge I implemented.

Yes, we generally need to work on keyboard navigation in KDE4.

>   3.  Too many apps capture TAB and Shift-TAB unnecessarily, and even if
> they must capture them (such as the KWord main document window), do not
> provide alternative ways to move focus out of the widget without a mouse.

Gnome offers Ctrl+TAB as an alternative keyboard shortcut for moving the 
focus. Qt does the same if an XDG setting is set appropriately, but 
unfortunately this clashes with the default KDE keyboard scheme.

>   4.  Not all widgets honor the high contrast and big themes.  For example,
> in KOffice, the font dropdown widget, in an effort to render the font names
> in each font, forgets to size the text according to the theme, and
> therefore does not display the list in large text when a big theme is in
> effect.

This is exactly what we wish to solve with the new guidelines on colour 
schemes.

Can your mail provider handle a big mails (about 1 MB)? Then I would like to 
send you the draft for review.

> I don't think we have enough manpower in the kde accessibility team to fix
> all the problems.  We need a commitment from the core developers and from
> the kde community to fix problems and not implement new ones.  The lesson I
> learned from my attempts to improve accessibility for KOffice is that the
> "bolt on" approach works badly or not at all.  The kde accessibility team
> will have its hands full just identifying the issues.

I fully agree.

Olaf

-- 
Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
accessibility networker, Protestant theology student and webmaster of 
http://accessibility.kde.org/ and http://www.amen-online.de/


More information about the kde-accessibility mailing list