I spoke to Jeff briefly during CSUN this year. I haven't played with it
extensively, but some basic comments:
As for the base concept - I like it. It's a truly zero install, web
based screen reader, unlike SAToGo, which is a temporary install. In
other words, this will work anywhere that allows web access and has some
media playing abilities.
In order to run completely in the browser, it has to fetch all of the
audio from the server (it can't install a TTS engine). It uses flash,
and fails over to other media players. In order to reduce latency, they
cache the audio files for replay. I didn't notice any latency issues,
but I have a better than average connection.
I had some concerns that it wouldn't be able to read dialogs, but it
looks like they feed the websites through PHProxy, which converts things
like password dialogs into HTML pages. This makes me a little nervous
because my password is being intercepted, but its an inventive
workaround since they wouldn't normally be able to read that dialog. I
don't know if they are able to intercept all dialogs though.
* One of the issues that we had with HPR was that a solution that only
accesses the web pages is a fairly limited solution. In order to access
the browser chrome, or other applications, a more general purpose screen
reader is needed. If you have to install a screen reader to access the
rest of the desktop, it somewhat defeats the purpose of the browser
based solution. However, this can still be useful in public access
environments that do not offer screen readers (better than nothing).
* While caching helps the second time around, even a smart pre-fetch
algorithm will be painful if the bandwidth is low enough. What's the
minimum bandwidth required to be usable? It seems fairly low, but I'd
just like to know what it is.
* Regarding the intercepts of web pages & dialogs, what are the
* How scalable is the server?
* The item reading seems funky to me. It stops at all punctuation, even
commas. Certainly easy enough to fix - just needs more work.
Bottom line: It's a nice research prototype, and solves a specific
problem - screen reader access on secured machines (e.g. can't install
anything, and can't execute downloaded files).
dev-accessibility mailing list
[hidden email] https://lists.mozilla.org/listinfo/dev-accessibility
Thomas Brunet wrote:
> * Regarding the intercepts of web pages & dialogs, what are the
> security/privacy implications?
You certainly would need to trust whoever is serving your WebVisum
instance, although since it's FOSS you could always install it on your
I'd still be worried about pages visited with WebVisum hijacking the
interface through some sort of cross-site scripting and gaining access
to passwords that way. That's just speculation however.
> Bottom line: It's a nice research prototype, and solves a specific
> problem - screen reader access on secured machines (e.g. can't install
> anything, and can't execute downloaded files).
Other potential use-cases:
1. Experimenting with new screen reader interfaces and algorithms since
end-user testers wouldn't even need to install it.
2. Improved web access over your primary screen reader. For example, you
could be using VoiceOver but need proper table navigation or using an
ancient version of JAWS and need ARIA support for applications. (I don't
think WebVisum has ARIA support yet, but you get the idea.)
Currently WebVisum streams sound over a Flash socket. I wonder if
there's any way to stream text to a braille output device and support
braille users too, in Flash or anything else. It's theoretically
possible, but are there existing interfaces already in place?