I have taken a similar approach as the one you suggest using HTML + Javascript. I can’t say that my efforts represent anything close to best practices when it comes to my “Web Page Communicator” package either as an example of Javascript programming or as HTML design. My efforts have been largely the results of trial and error, and rooted in my largely procedural programming training. All you can say about my stuff is that it works to some extent, and that it works across several browsers. It demonstrates that the concept of a virtual communication device, independent of platform, or browser is possible – and achievable without dependency on proprietary, non-standards based technology. HTML5 should help to make this easier to realize.

See: http://sites.google.com/site/jamjolu/Home/web-page-communicator

I don’t use text-to-speech (although I have in past attempts using VB script for Internet Explorer and the Microsoft Agent) because it seemed more likely that audio files would be more easily supported across more browsers and platforms. This hasn’t been as true as I would like. Also, keyboard input is handled inconsistently across browsers, and as a result in my current version keyboard driven scanning modes in the Safari and Chrome browsers just don’t work. I would like someday to solve these problems. Ultimately, I would like to see the web page approach succeed in mobile devices as well.

Currently, I too would like to completely overhaul my package to meet the following criteria:

1. The basic web page communicator page would contain support for the user interface methods (scanning methods,) speech output (tts, or audio files,) and linking and other behaviors. These pages would have two flavors – one for simple message playing, and another that permits sentence construction.

2. Content, arrays of “cells”, would be described separately using JSON structured files. Each cell would identify picture and sound files, and any specify desired behaviors. Cells could optionally be grouped for row/column scanning.(Another approach could use inline frames to load content web pages.)

3. User interface preferences like which scan method and switch interface specifics an individual requires would also be described in a separate JSON file.

4. An external CSS file would cover other user visual preferences.

5. A new simple editing tool like “formEdit” would allow users to create content sets, and to define preferences offline.

This approach would lend itself well to both offline users and to a Server/Client model. Content could be shared between users who have differing platforms and access methods.

Let me know what you think. I would most definitely like to collaborate, or to contribute towards advancing the concept of the web page communicator.

Regards,

Jim Luther

I’m very interessed in working with you for a new version with update plugin.

I’m working with disabled person in Italy and I’ve usually working with PVoice.

Let me know if you are interessed.