[Kde-accessibility] Timeframe for KDE 4

[Gary Cramblitt]

On Monday 20 February 2006 13:28, Gunnar Schmi Dt wrote:
> Hello,
>
> As you may know I am one of the members of the Technical Working Group
> (TWG). In order to make sure that the decisions made in the TWG are
> acceptable by the HCI related projects I would like to get some overview
> about the planned features and the expected time that is required in order
> to implement them.
>
> I know about the following efforts:
>
> 1. Integrate support for screen readers and other assistive technologies
> into KDE (via QAccessible and Qt-SPI)
>
> In order to support assistive technologies in KDE we need to provide
> QAccessible information for all KDE widgets that are not based on Qt
> Widgets or that significantly change purpose of the widget. Implementing
> this information can be done without heavy changes to the API, but it
> requires a lot of work which can start as soon as we have a tool for
> testing the information. Harald Fernengel will provide us with that tool
> as soon as we have DBUS support in KDE.

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.  See 
this thread:

http://lists.kde.org/?l=kde-accessibility&m=113469521917985&w=2

>
> 2. Updated guidelines and widgets for colors, fonts and icons
>
> Olaf, Ellen and I are currently discussing new guidelines for colors, fonts
> and icons (we intend to send them to the HCI list for a discussion
> sometime in the next days). These guidelines will require some changes
> both to kdelibs and to many applications. Implementing the changes in
> kdelibs is not much work (can be done in less than a week), but for
> changing the application we would like to have the help of the individual
> application developers.

Yes

> 3. Implement the usability enhancements shown on
> http://test.openusability.org/wiki_ou/index.php/Libs

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.

In addition, while evaluating KOffice 1.4 for accessibility, I noted several 
problems that are best fixed in the Qt or KDE libraries.  KOffice 1.5 
attempts to fix these problems by "bolting on" kludges, but they really need 
to be fixed in the core libraries.  In particular:

  1.  Toolbars cannot be navigated without a mouse.

  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.

  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.

  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.

What is needed is some effort to determine if these (and other a11y) problems 
exist in Qt4/kdelibs4 and solve them.  Some of them, such as sizing of 
QSplitter and QDockWidget will be tough to fix.  The AT-SPI interface might 
provide a means for workarounds, but these problems should really be 
addressed at the core level.   This is really two tasks: 1.  Identify the 
issues, and 2.  Fix them.  Identifying the issues has been on my TODO list 
for awhile, but kdelibs4 has not been far enough along or stable enough to do 
it.

>
> 4. Changes to KTTSD
>
> For KDE 4 there are a number of changes to the KDE Text-To-Speech system.
> They include:
> - Integrating  kttsd, KSayIt, the various kttsd plug-ins for kate /
> katepart / khtmlpart / koffice, and maybe kabook into a consistent user
> interface
> - Move KTTSD to SpeechDispatcher.
> - Simple speech feedback (focus tracking, mouse-over, etc.) for use with or
> without a magnifier

I guess it is time for me to write a roadmap for KTTS migration.  :)

>
> 5. Improving existing KDE Accessibility programs (and possibly including
> some new ones)
>
> Open questions are:
> - How much time do we need for implementing the above efforts?
> - Who will implement the kdelibs changes for 2.? It can be done by the
> people involved in the kdeaccessibility project, but that will delay other
> important accessibility work.

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.

> - Did I forget important HCI-related efforts that need to be considered in
> the release planning for KDE 4?

-- 
Gary Cramblitt (aka PhantomsDad)
KDE Text-to-Speech Maintainer
http://accessibility.kde.org/developer/kttsd/index.php