[Kde-accessibility] an idea i have been thinking about

[Gary Cramblitt]

On Saturday 12 November 2005 05:51 am, david powell wrote:
> problems that i can see from a blind persons point of view
> and a possible way that could be tackled to try and solve it
>
>
> mainly i had the idea to the solution before it accured to me
> how bad the problem needs to be looked at
>
> i was initaly thinking of using the current avalable tts with the view
> to creating wav/ogg files that could be used in standard knotifications
> where the tts is not avalable
>
> then it sort of accured to me that if there is no tts configured in kttsd
> how easy would it be to auto detect a tts and try to do install it
> but then i spotted the bigger problem
>
> it may be posable for a blind person to get the machine set up in the first
> place
> by someone for them , but after that they are pritty much on there own ,
> and any problem
> and configuration would realy need someone there who can help them
>
> maybe ok in an educational establishment but when thay need to call an
> technition or friend
> over to help then it can get too much for them to constantly ask for help
>
> anyway
> was thinking that it should be possible to build a script that would auto
> detect and configure
> kttsd's voices
> as it also accuerd that the kttsmgr interface could be hard to use , and in
> most cases imposible if
> not configured with a voice
> (this is assuming a working screen reader )
>
> so the idea came to create a audio driven menu system to aid configuration
> of it
> (and maybe other things later )
>
> anyway partly would depend on the feature request i posted but in its self
> is a diferent application
> idea
>
> using a hotkey ( in kde ) the following program (description of it ) should
> be started
> think it should be part of kdeaccessibility
>
> a driven speech configuration script
>
> to do this  without a tts configured it will use audio files (.wav or .ogg)
> that contain the menu options
>
> the actual text to be spoken will be the translation of the text recorded
> as a wav by tts for the avalable tts languages
> that we can currently use (so to be fair we dont have french but we dont
> have a french voice to use anyway )
> so it is posable to get translations
>
> giving an option system in a way like you get on those phone menues " press
> 1 for .... etc  would alow it to be used
> and let a blind person be able
>
> by using pre recorded tts output in the distribution we can get it to speek
> in any language that we have a voice for
> so even if the default language of izulu was that the user has selected as
> the desktop , the menu audio will play in that
> even if that voice is not installed or canot be found
> so the user will get a spoken mesage back even if the tts will not start
>
> if this application can be started on kde login it would be benifical to
> people who are blind or low sighted
> as i feel that thay could be totaly lost if there tts fails
>
> anyway dont know what you think , but could posibaly be extended to other
> functions
> maybe include menus for system functions , or to start some other
> applications also
>
> i dont think it will be a replacment for a screan reader but feel that it
> may be a verry usefull seprate
> package that does not depend on the tts system working
>
> basicaly its an attempt to provide a method so that a blind person may walk
> up to a machine (with kdeaccessisbility installed )
> and within a short time should be able to have any avalable tts software
> enabled and working
>
> idea open to descussion , and guess it needs a developer or two willing to
> write it
>
> (hope it makes sense )
>
> Dave

Thanks for the great ideas David.

First, kttsd already automatically configures a talker when it is first used 
and no talkers have been configured.  For this to work, the synth plugins 
have to be able to find the synth executables in the PATH.  In the case of 
Festival, it does exactly as you suggest and performs a voices.list command 
and looks first for a known voice that matches the desktop language setting, 
and if not found, falls back to English.

As you know, it is my plan to migrate ktts to use Speech Dispatcher as its 
backend engine for KDE 4.  However, all this does really is move the domain 
for your suggestions from the KDE startup to the operating system startup, 
i.e., Speech Dispatcher should automatically try to configure its backends 
when it is started.

Of course, prior to KDE starting, there is no GUI, but in principle, SD could 
prompt a blind user just as you suggest, with pre-recorded voice prompts.  I 
see no technical obstacle to that and will suggest it to the SD team.

As for other speech integration within KDE.  All of that is possible today, 
but the best approach would be better integration with an assistive 
technology architecture.  That's what Qt/KDE4/AT-SPI integration is all 
about.  If all widgets, menus, icons, etc., have built-in core support for 
AT-SPI, then a screen reader or other AT can improve access to the entire KDE 
desktop, and not just for the blind using speech, but for people with other  
disabilities and using the assistive tools that are most appropriate 
(braille, etc.)

Given that, it doesn't make a whole lot of sense to put our energy into adding 
speech capabilities to KDE 3.x now, when a better solution will be available 
in KDE4.  I'm not saying *not* to speech enable menus and such, but given the 
few resources (people) we currently have, I would prefer to see people 
working on KDE4 and AT-SPI integration.

If someone is itching to implement your ideas now, I'd be willing to help out, 
but keep in mind that KDE 3.x is currently in freeze, so it will be a 
challenge.

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