Edgy Accessibility features

[Gary Cramblitt]

On Saturday 22 April 2006 08:26, Luke Yelavich wrote:
> On Sat, Apr 22, 2006 at 03:27:26AM EST, Henrik wrote:
> > This is the time to start floating some ambitious new ideas. Let's do
> > some brainstorming on this and get some of the doable things on the wiki
> > as specifications. Let's think beyond what Windows or OS X has (each
> > with it's proprietary add-ons) and think about what users really need.
> >
> > So, some ideas:
> >
> > Orca User Interface -- I've been talking a bit with the Orca team about
> > working on the configuration UI. We in Ubuntu have a good community that
> > can provide valuable ideas and testing for this and Orca seems to run
> > quite happily on the Ubuntu platform. Orca has been put forward for
> > inclusion in gnome 2.16, which IMO is the right move, but for that to
> > happen it probably needs a config UI (be it GUI or not).
>
> Agreed. I also don't like the idea of using a separate program, i.e
> orca-setup just to get orca configured for the user. IMO that should be
> done when orca first runs, and not in a terminal.
>
> > General AT config UI -- I feel that the AT settings in gnome are handled
> > a bit awkwardly and could do with a rethink and some centralisation.
> > This should be seen in context with the point above. I'd like to see an
> > extensible config utility where different apps could plug in.
>
> Yes, and standardize back-ends for things, such as speech-dispatcher
> rather than gnome-speech, etc.

Hynek and I were discussing the issue of configuration files and GUIs for 
Speech Dispatcher just yesterday.  ATM Speech Dispatcher uses dotconf to read 
its configuration files.  dotconf files are reasonably easy to edit with a 
text editor, but we agree that a user-friendly GUI and/or command-line 
interface would be better.  One idea is to develop a library for reading and 
writing of the config files that can be used for the GUIs in both KDE and 
GNOME.   We want terminal-based users to be able to perform configuration as 
well as GUI users.  I was also thinking about gconf and kiosk.  Is there a 
common configuration file format that could be controlled by admins setting 
up both GNOME and KDE desktops for LAN users?  Throw in a requirement for a 
central configuration for all AT components and the issue gets even more 
complicated.  Hynek and I would appreciate some guidance.  It's beginning to 
look like this thread needs to move to the accessibility at freestandards.org 
mailing list.

>
> > XGL-based screen magnifier -- The new desktop rendering technologies
> > using the 3D rendering hardware hold great promise for screen
> > magnification. We already see the zoom features demoed on XGL systems
> > magnifying faster and smoother and with better clarity than the existing
> > magnifiers like kmag or Gnopernicus. However, in order to be useful for
> > low vision users features like cursor tracking will be needed along with
> > general configuration tools.
>
> Is there anything that can be played with at the moment along these
> lines?

Recommend you contact Gunnar Schmi-dt (I've CCed him).  He has developed a 
very nice screen magnifier that takes advantage of transparency.  I'm not 
sure if it uses XGL or not.  He developed it for his Masters thesis.  I 
believe he is waiting for permission from the university to release the code.

>
> > Speech dispatcher -- According to their website the SD gnome-speech
> > driver will soon be shipped with gnome-speech. How mature is this?
> > Should we standardise on SD for speech output in Ubuntu? What else is
> > needed, configuration interfaces? (as you can read I don't know very
> > much about this technology, so others please fill in the blanks.)
>
> KDE are planning to use speech-dispatcher for their back-end. IMO Sun
> were stupid in creating gnome-speech, although I am pretty sure they did
> it at a time when there wasn't really anything else. There was a post on
> one of the GNOME lists recently about having two back-end systems, one
> chained to the other, being pointless. IMO we rip the gnome-speech
> support out of orca, and use speech-dispatcher directly. I am pretty
> sure SD has python bindings, and speech-dispatcher as far as I have seen
> is a ittle easier to program for.

KTTS is indeed planning on using Speech Dispatcher for its backend.  The 
roadmap is here:  http://accessibility.kde.org/developer/kttsd/roadmap.html

Hynek agrees it would be better if Orca interfaced directly with Speech 
Dispatcher.  The Gnome-Speech Dispatcher component is very basic right now.  
You can't easily switch languages or voices, for instance and you can't take 
advantage of the SD features that are tailored for screen readers (such as 
progress messages.)  Ultimately, however, this is up to the Orca devs and 
they could probably use a lot of help right now.

Something I'm wondering about is Speech Dispatcher audio output and GNOME.  
ATM, SD can output audio via ALSA, OSS, or NAS.  (Since I'm not a GNOME user, 
the following could be all wrong.)  It is my understanding that ESD locks the 
audio device.  Therefore, a GNOME user who uses ESD cannot hear anything from 
SD.  If that is right, should SD be looking at adding an ESD audio plugin?  
OTOH, I believe GNOME is deprecating ESD in favor of GStreamer.  So I was 
thinking about a GStreamer plugin for SD.  However, GStreamer is not a sound 
server, so it is unclear to me how SD interfaces with GStreamer.  Judging 
from the GStreamer applications developer manual, it seems that SD must set 
up a complete pipeline (from SD as the source to a sink such as ALSA or OSS).  
I don't think SD should be doing all that.  I also thought perhaps the SD 
audio plugin should be a push source plugin, but then how does the pipeline 
get set up?  We are also concerned about performance issues in both ESD and 
GStreamer.  If someone could clarify these things for me, I'd appreciate it.


>
> > KDE -- What's cooking in KDE 4? We have seen talk about gnome and KDE
> > using the same AT infrastructure. What is the state of this and is there
> > anything ubuntu/ubuntu can do to help? The idea is that KDE4 apps will
> > use AT-SPI, right? So will they simply work with Orca and GOK or will
> > new KDE AT apps be written?
>
> The GNOME and KDE accessibility teams are still trying to standardize
> the at-spi stuff, but I don't know when that is going to happen. I
> suggest those who are interested at least join the kde-accessibility
> mailing list to get an idea of what is happening. You can subscribe
> here: https://mail.kde.org/mailman/listinfo/kde-accessibility

GNOME and KDE are indeed planning to unify around the AT-SPI for KDE4.  If 
that happens, the ATs in GNOME would work with KDE4 apps and the ATs in KDE 
would work with GNOME apps.  The biggest obstacle right now is the use of 
Orbit/CORBA.  KDE would like to see a migration to DBUS, but how we get 
there, and the intermediate steps is unclear.  There is also a shortage of 
people willing and able to work on this, so not much is happening ATM.

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