Hi, Gerhard,
You are not totally off track, in fact, you're pretty much on it, but the fact remains that I need it to work without a screen reader.
I have implemented this by means of MSAgent, using the MS SAPI for defaults, and, if available, the AT&T TTS engine, which has much better sound. This works fine, but to implement this, you'd need to hack at Drupal by adding another module, not even necessary to be a core module.
I have very specific needs here - the text said and the text spoken might not be the same, and you might want to speak only part of the text, similar to only reading a part of the text. This can be done by parsing HTML/XHTML for <h1> .. <h6> tags and parse the text between them as sections, or, by treating the texts as different paragraphs. For example, if the user module has:
==================
[ Log in tab ]
Username: [ ] Enter your Project EagleEyes username
Password: [ ] Enter the password that accompanies your username
[ Log in ]
[ Register tab ]
Username: [ ] Your full name or your preferred username; only letters, numbers and spaces are allowed.
Password: [ ] A password and instructions will be sent to this e-mail address, so make sure it is accurate.
[ Create new account ]
==================
I want the text to be:
<h1>Login</h1> Press tab then type your username, followed by pressing tab and type your password. Complete the login process by pressing ENTER <h1>Register</h1> Press tab then entered your desired username, followed by pressing tab and type in your e-mail address. Further instructions will be sent to your e-mail address.
(or something like that...)
If you create a new language for this purpose, you'd have to create a second language for any recognized language, e.g. EN_UK (text) and EN_UK (spoken). If you do this with my method, this would not necessarily make it less work for the end user, but it will definately make it less work for the person setting up the site and offer more usability for Drupal out-of-the-box, as your method would pretty much mean that you have to patch all the different t() strings into a readable page. Look at any language, it contains short words, not complete sentences or paragraphs, except in the case of the help sections, and with locale's inherent problem that it is difficult to place such short words or phrases within context, this will be disastrous.
Regards,
Kobus
killesreiter@physik.uni-freiburg.de 9/2/2005 3:41 PM >>>
On Fri, 2 Sep 2005, Kobus Myburgh wrote:
- As I said - sometimes you don't want to speak the exact text than
what you print on the page, as per my login example below.
- I want the site to work for ANYONE, not just those with screen
readers. This site must talk for someone even without a screen reader.
Now, maybe my route is still not optimal, and introduces problems that would otherwise not be present, but considering my circumstances and my requirements, it would defeat the purpose to let the client's T2S handle this.
The question now is - when I get this to work (oh, and I will...) should I contribute it to Drupal, if it is not optimal?
Kobus, I think you are missing something. :)
The way I would approach the problem is to treat text that needs to be read to the blind as a separate language. I would try to redirect them to that site based on user agent or by giving a link on the top of the main site. The site would share the content with the main site if this is desirable. You can then simply create PO files for that site and let the screenreader do the rest. If you need a different formatting for links, you can hack the l() function.
Is that a good idea or am I off the track?
Cheers, Gerhard