Ber,
The reason why I am going this route is because:
1. Many people can't afford commercial screen readers. 2. Most of the screenreaders in the open-source/freeware market that I've evaluated simply sucks, to say the least. 3. 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. 4. Most of the times, a person who has never used a computer for more than a simple word processing task before (like my blind girlfriend), understanding the open-source movement will be a daunting ask. She doesn't even understand Windows, how will she understand that? It must "just work" when she opens her browser. No questions asked, no nothing. 5. 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?
Regards,
Kobus
berdrupal@tiscali.be 9/2/2005 2:40 PM >>>
Kobus.
I read myself into KDEs text-to speech stuff. And frankly I am very surprised by your route.
FRom what I learned, modern T2S synthesisers deal with (valid) XHTML in a very good way. In other words: just use the proper XHTML, optionally with Speech CSS and let the clientside software handle your sites. I fail to see why you would want to present users with speech on server side, if they can very well deal with valid pages.
Mohammed al-shar, welcome. I am very sure you will be a very valuable addition to the Drupal team. People who have good (first-hand) knowledge about speech and web, or braille terminals and XHTML can be of great help to improve Drupal even more. Welcome!
Ber
Op vrijdag 02 september 2005 09:03, schreef Kobus Myburgh:
Ber,
Sometimes it might be inappropriate just to speak whatever is on the page, because it will not be clear to follow - this much I have noticed. Look, for example, at a simple login page, what do you see?
Username: [ ] Password: [ ]
If you're going to hack t() to speak the text, it will read to you 'Username Password'. For blind users it might be useful to give a bit more instruction. Sighted users can use intuition to understand that the empty space means "username goes here" and "password goes here", but a blind user won't necessarily know that. The concept of "here" is not applicable to them. You can't say "click here" or "provide your e-mail address here".
Immediate thought here would be:
- Hack t(), as you suggested, by adding a parameter, say, sid, which
refers to the content of #2. 2. Make a new table in the database with the exact text to speak on each system page, and use the sid parameter to retrieve that information from the database and speak it, if available.
This would allow us to accomplish:
- Keep the site's output to be regular for normal site visitors
- Speak the normal t()'d text if the new database entry is not provided
- Speak the alternative text if provided
This would require one of two things:
- Patching each and every core module, finding instances of t() and fixing
them 2. Introduce a new function, say, s(), which will have one text string for each different page in Core.
I assume #2 would be the easiest, but that s() would have to reside in a module, and be globally available, and tested for its presence with "if (module_exists(speech))..." or something like that?
Thanks for pointing me in the right direction! I will get to work on that immediately... :-)
Regards,
Kobus
berdrupal@tiscali.be 9/2/2005 12:52:22 AM >>>
Kobus,
No I did not test it. I still need to figure out how to get my speech stuff working in KDE. I just came with the idea for a theme, because ALL content is ran trough themes. So you can easily do magic to any page in your theme. or example return an ogg instead of HTML.
But, as said: all content all strings are ni the transatiopn databasze, so I think an easy way is to hack t(), so that it calls a speech function.
Ber
Op donderdag 01 september 2005 16:59, schreef Kobus Myburgh:
Ber,
I will happily contribute the speech theme, however, most of my stuff is not theme related. It is a module I wrote, and I need to speak the text that is in Drupal core and modules, not content that I added to the site. Did you test it out? Does it work on your side? Could you see my ideas?
Regards,
Kobus
berdrupal@tiscali.be 9/1/2005 4:48:56 PM >>>
Most texts are ran trough t(), I guess you can use that? otherwise some of the theme function might help you along. A speech theme would be very cool.
Op donderdag 01 september 2005 11:12, schreef Kobus Myburgh:
Hi,
I have implemented a Drupal site with MSAgent for a project I need to do for my studies, as well as part of the ongoing project that I am working on at: http://drupal.org/node/22997.
I have created a module that adds a few fields to every node that you create, namely:
Spoken text (same as $node->body if not entered) Spoken title (same as $node->title if not entered) etc.
While this works relatively well for published content, it will obviously not work for Drupal's system pages, e.g. the user login page or administration pages. Do I have to hard-code this into the Drupal modules, or is there a way I can extend all system modules to have customizable texts which can be spoken? If you need more access on the site to be able to create content and work on this project with me, please let me know.
If you want a demo of the problem I am experiencing, please take a look at www.eagleeyes.co.za (currently only tested with IE6...) There will be a security message coming up, which you can decline. It is only to allow speech in the menu (will not be asked again if you put the site in your trusted zones in IE). The speech of the content will work regardless, providing you have a TTS Engine installed. This is usually installed to a degree with a standard Windows XP Pro install, so you shouldn't experience any trouble.
If you look at the main page, you will see that the text is spoken to you, but if you click in the menu on the System -> Maintenance, you should be provided with an Access Denied message. When you press Control+Shift+J to activate speech, you will see what I mean.
Any ideas would be greatly appreciated.
Regards,
Kobus
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] -- [ Drupal support list | http://lists.drupal.org/ ]
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] -- [ Drupal support list | http://lists.drupal.org/ ]
Regards, Bèr
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
okay OT. But this mus be said:
Yuo make the sam mistake as a lot of peolpe see mto make: OSS is NOT -i repeat- NOT more difficult than windows. recent test pointed out that esp for visual or otherwise handicapped people linux was easier to install, maintain and use!. And really, winXP is harder to install and use then ubuntu. that was teh outcome of that same invistigation.
But OT again: I do understand your ideas and why you chose the route you want to take. I just wanted to point you at the fact that there are quite good defautls and systems around. I know KTTS with festival does fine. I use it to read long posts and mail-threads to me when I am cooking or cleaning or so :). I know other screen readers all work client side. And i know there is a lot of development to improve reading of HTML and text on that client side. I have never come across a site that reads to me from server side, though it would be very interesting. But my main concern is that server side is just not standards safe. What are you going to use? mpg streams? AAC? ogg? none of them are natively supported by all systems, since none are standards, most are even closed and patented formats.
But all in all I think your idea is great. And I think you should consider the most general approach, either by making a language/translation, or by providing a speech theme, for that will catch all content. (isn't speech not just another way of 'looking' at the content?)
Op vrijdag 02 september 2005 15:08, schreef Kobus Myburgh:
Ber,
The reason why I am going this route is because:
- Many people can't afford commercial screen readers.
- Most of the screenreaders in the open-source/freeware market that I've
evaluated simply sucks, to say the least. 3. 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. 4. Most of the times, a person who has never used a computer for more than a simple word processing task before (like my blind girlfriend), understanding the open-source movement will be a daunting ask. She doesn't even understand Windows, how will she understand that? It must "just work" when she opens her browser. No questions asked, no nothing. 5. 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?
Regards,
Kobus
berdrupal@tiscali.be 9/2/2005 2:40 PM >>>
Kobus.
I read myself into KDEs text-to speech stuff. And frankly I am very surprised by your route.
FRom what I learned, modern T2S synthesisers deal with (valid) XHTML in a very good way. In other words: just use the proper XHTML, optionally with Speech CSS and let the clientside software handle your sites. I fail to see why you would want to present users with speech on server side, if they can very well deal with valid pages.
Mohammed al-shar, welcome. I am very sure you will be a very valuable addition to the Drupal team. People who have good (first-hand) knowledge about speech and web, or braille terminals and XHTML can be of great help to improve Drupal even more. Welcome!
Ber
Op vrijdag 02 september 2005 09:03, schreef Kobus Myburgh:
Ber,
Sometimes it might be inappropriate just to speak whatever is on the page, because it will not be clear to follow - this much I have noticed. Look, for example, at a simple login page, what do you see?
Username: [ ] Password: [ ]
If you're going to hack t() to speak the text, it will read to you 'Username Password'. For blind users it might be useful to give a bit more instruction. Sighted users can use intuition to understand that the empty space means "username goes here" and "password goes here", but a blind user won't necessarily know that. The concept of "here" is not applicable to them. You can't say "click here" or "provide your e-mail address here".
Immediate thought here would be:
- Hack t(), as you suggested, by adding a parameter, say, sid, which
refers to the content of #2. 2. Make a new table in the database with the exact text to speak on each system page, and use the sid parameter to retrieve that information from the database and speak it, if available.
This would allow us to accomplish:
- Keep the site's output to be regular for normal site visitors
- Speak the normal t()'d text if the new database entry is not provided
- Speak the alternative text if provided
This would require one of two things:
- Patching each and every core module, finding instances of t() and
fixing them 2. Introduce a new function, say, s(), which will have one text string for each different page in Core.
I assume #2 would be the easiest, but that s() would have to reside in a module, and be globally available, and tested for its presence with "if (module_exists(speech))..." or something like that?
Thanks for pointing me in the right direction! I will get to work on that immediately... :-)
Regards,
Kobus
berdrupal@tiscali.be 9/2/2005 12:52:22 AM >>>
Kobus,
No I did not test it. I still need to figure out how to get my speech stuff working in KDE. I just came with the idea for a theme, because ALL content is ran trough themes. So you can easily do magic to any page in your theme. or example return an ogg instead of HTML.
But, as said: all content all strings are ni the transatiopn databasze, so I think an easy way is to hack t(), so that it calls a speech function.
Ber
Op donderdag 01 september 2005 16:59, schreef Kobus Myburgh:
Ber,
I will happily contribute the speech theme, however, most of my stuff is not theme related. It is a module I wrote, and I need to speak the text that is in Drupal core and modules, not content that I added to the site. Did you test it out? Does it work on your side? Could you see my ideas?
Regards,
Kobus
berdrupal@tiscali.be 9/1/2005 4:48:56 PM >>>
Most texts are ran trough t(), I guess you can use that? otherwise some of the theme function might help you along. A speech theme would be very cool.
Op donderdag 01 september 2005 11:12, schreef Kobus Myburgh:
Hi,
I have implemented a Drupal site with MSAgent for a project I need to do for my studies, as well as part of the ongoing project that I am working on at: http://drupal.org/node/22997.
I have created a module that adds a few fields to every node that you create, namely:
Spoken text (same as $node->body if not entered) Spoken title (same as $node->title if not entered) etc.
While this works relatively well for published content, it will obviously not work for Drupal's system pages, e.g. the user login page or administration pages. Do I have to hard-code this into the Drupal modules, or is there a way I can extend all system modules to have customizable texts which can be spoken? If you need more access on the site to be able to create content and work on this project with me, please let me know.
If you want a demo of the problem I am experiencing, please take a look at www.eagleeyes.co.za (currently only tested with IE6...) There will be a security message coming up, which you can decline. It is only to allow speech in the menu (will not be asked again if you put the site in your trusted zones in IE). The speech of the content will work regardless, providing you have a TTS Engine installed. This is usually installed to a degree with a standard Windows XP Pro install, so you shouldn't experience any trouble.
If you look at the main page, you will see that the text is spoken to you, but if you click in the menu on the System -> Maintenance, you should be provided with an Access Denied message. When you press Control+Shift+J to activate speech, you will see what I mean.
Any ideas would be greatly appreciated.
Regards,
Kobus
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] -- [ Drupal support list | http://lists.drupal.org/ ]
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] -- [ Drupal support list | http://lists.drupal.org/ ]
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ] -- [ Drupal support list | http://lists.drupal.org/ ]
Regards, Bèr
-
Bèr Kessels -
Gerhard Killesreiter -
Kobus Myburgh