[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Help needed: People willing to help co-maintain debian accessibility packages

Hi Mario,

>>>>> "ML" == Mario Lang <mlang@debian.org> writes:

    ML> Since speechd-el is more or less a direct replacement for
    ML> Emacspeak which was called into existance because of frustration
    ML> with how certain things work in emacspeak, I kind of doubt he
    ML> (milan) is interested in maintaining emacspeak.  OTOH, it would
    ML> of course be wonderful, since much of the required knowhow to do
    ML> the job properly is already there.  Milan?  <blink> :-)

All our GNU/Linux users happily moved from Emacspeak to speechd-el, so I
have no interest to get involved with Emacspeak anymore.

As for the other issues you presented, I agree accessibility in Debian
and Free Software generally needs much more help.  Unfortunately
Brailcom currently lacks resources to invest more than it already does
into this area and my free time is very constrained for RL reasons, I
had to cut off almost all my personal software projects.

My personal interest areas where I might be able to help are:

- Accessible Emacs interfaces.  In this area, speechd-el is maintained
  and further developed by Brailcom.  I personally don't think this is
  the best approach to make Emacs accessible, but I think it currently
  provides the best value interim solution and is going to play the role
  for the several next years.  Additionally, it's a good testing
  platform for some accessibility concepts.  So it's worth to invest
  into it.

- Common accessibility infrastructure.  Brailcom develops Speech
  Dispatcher and we started to cooperate with KDE on extending the
  Speech Dispatcher and KTTSD concepts to cover more application areas.
  There was also work on a common API to text-to-speech systems, but
  it's stalled now since all participants lacked resources to work on it
  further.  The only other party I could see any care about this project
  recently is KDE.  Apparently we need some impulse here.  A similar
  project is the work on audio framework requirements, where Brailcom
  cooperates with KDE again and which seems to be promising.
- Free speech synthesizers.  I think that free speech synthesizers
  provide good basis to serve the accessibility issues in both the areas
  of the quality and features today.  Namely, Festival provides usable
  to very good free English voices.  Free voices for other languages
  appear -- Brailcom works on Czech (already usable), Klaus Knopper
  works on German, I've heard about Italian and Russian, perhaps someone
  still works on French.  The Epos project has recently released very
  good Czech voices under a DFSG compatible (it seems) license.
  Festival extensibility and ability to serve various accessibility
  related issues is demonstrated by our festival-freebsoft-utils
  Work on supporting non-free speech synthesizers (except for the work
  on the common TTS API) is IMHO waste of our limited resources which
  could be better spent on supporting the relatively wide range of
  activities towards free speech synthesis.

- Braille output.  Both BrlTTY and libbraille teams make good work here,
  the task is to improve their use in applications.  Brailcom makes its
  contribution by adding BrlTTY support to speechd-el.

- There are other smaller projects we do, e.g. sound-icons.

- Making X applications accessible.  I consider that being a very
  important issue, IMHO this is the place where accessibility efforts
  should be put primarily now.  The current state is discouraging from
  the point of view of end users, but encouraging from the point of view
  of developers.  AT-SPI is here and it's supported in GTK and Qt.  One
  of the problems I can see is the integration of all the tools into a
  working system.  Looks like something Debian could deal with.

Not all these areas are necessarily related to Debian directly.  But
when thinking about Debian accessibility, we should consider the
direction where Free Software accessibility moves generally and where
Debian can help best.

My vote for the very next Debian accessibility project actions would be:

- Providing up-to-date versions of the gnopernicus and brltty packages
  in unstable.

- Making the accessibility issues of debian-installer more visible in
  this mailing list.

- Making the project goals more visible here as well (e.g. as you did
  with your original mail) so that more attraction could be brought to
  the pending tasks and the Debian accessibility project generally.


Milan Zamazal

Why waste keystrokes when you can waste CPU cycles instead?
						Karl Fogel

Reply to: