From: Bill Haneman ([email protected])
Date: 01/27/03
On Wed, 2003-01-22 at 03:00, Aaron Leventhal wrote:
> Peter,
>
> I don't think he can use GOK, does it run on the win
> platform?
I don't see any big obstacles to getting GOK to run on win32. GTK+ has been ported to win32, as has ATK. GOK has a couple of additional dependencies which could be managed without too much trouble, but you'd need to integrate GOK's input device support with win32 devices. Here again, I don't see this as being a big job, and for Michael's purposes since his input methods are unusual there'd be some work necessary there regardless.
As for Mozilla, since the mozilla codebase exports ATK on *nix already, GOK's more advanced features could readily be made available while running Mozilla provided Mozilla could be build with the ATK accessibility back-end on Win32. That seems quite doable in principle if nontrivial (you'd need to have the GTK+ win32 developer libraries installed).
Given the specialized nature of Michael's project there would need to be significant coding in any case. I think that the work required to make GOK run with an ATK-enabled Mozilla on win32 would be only a modest part of the total project, and it would have the advantages of offering a cross-platform solution which had more extensibility to applications other than Mozilla.
regards,
Bill
> > We are using our own neural signal processing
> > software, which is bound to a win platform but does
> > not currently offer any accessibility features (so
> > sadly we cannot use Gnome which seems to be a
> > wonderfully accessible OS).
>
> - Aaron
>
>
> Peter Korn wrote:
> > Hi Aaron, Michael,
> >
> > I'm cc-ing the GOK Development mailing list <[email protected]>. I have a feeling
> > that the GOK engineers aren't on the mozilla-accessibility mailing list.
> >
> > Michael - at the risk of repeating arguments Bill has made to you, I strongly
> > suggest you take a close look at GOK. They've done a lot to provide direct
> > access to menus, toolbars, and with their "UI Grab" feature, the contents of a
> > dialog box. These they then format onto a switch keyboard for rapid direct
> > access. While GOK does not presently do this with links on a web page, it would
> > be a very straightforward application of their techniquies layered on top of the
> > GNOME Accessibility API (through which an AT can enumerate the links in an
> > AccessibleHypertext document such as the web page in Mozilla).
> >
> > As GOK is open source, it is perhaps the best place for research - you can build
> > on the work of others to rapidly get the features you want, with no royalties or
> > licensing fees. And, thanks to the fact that it the code is LGPL, you have a
> > very strong incentive to contribute your work back to the commons - thereby
> > allowing the next person to build on your work.
> >
> >
> > By the way, I was recently at the Assistive Technology Industry Association
> > conference in Orlando, where I spoke with researchers in Japan working on a
> > brainwave<->switch interface, and other researchers in the U.S. looking at
> > switch interfaces based on recognition of a limited vocabulary from people with
> > highly dysarthic speech. Both were very interested in using GOK as a
> > development and execution platform for their switch interfaces.
> >
> >
> > Regards,
> >
> > Peter Korn
> > Sun Accessibility architect
> >
> > Aaron Leventhal wrote:
> >
> >>Michael,
> >>
> >>It sounds like a really interesting project. Will there
> >>be any way to access form controls in web content,
> >>bookmarks or any of the menus or other features? Or
> >>will it be for link activation and document reading only?
> >>
> >>I now understand your justifcation better for building
> >>it into Mozilla, using XPCOM. However, since you are
> >>currently only on Windows, did you consider the need to
> >>access other applications? Will the switch software
> >>possibly conflict with other switch software the user
> >>may be using to access those other applications? Will
> >>you need to work with switch solution manufacturers?
> >>
> >>As far as your other questions, I do think that forward
> >>and back options would be useful. You could possibly
> >>insert extra links or buttons for those things into the
> >>start of each page as it is loaded.
> >>
> >>I will be in Stuttgart for 6 months starting in May --
> >>perhaps we can meet and work on some solutions
> >>together. Have you tried to connect with any users or
> >>other experts in switch access? The Mozilla
> >>accessibility newsgroup is probably not the best place
> >>to do that -- accessibility on this platform is still
> >>being developed, so only cutting edge people are
> >>attempting to use those features.
> >>
> >>Good luck,
> >>Aaron
> >>
> >>Michael Bensch wrote:
> >>
> >>>Hi Bill and Aaron,
> >>>
> >>>your points are appreciated and certainly got me thinking. GOK is an
> >>>exciting project and maybe a good reason for switch users to switch to
> >>>Gnome :-)
> >>>
> >>>A large part of the research here at the Institute of Medical Psychology
> >>>and Behavioral Neurobiology in Tübingen is devoted to brain-computer
> >>>interfaces (BCI) ie. users with severe motor disabilities, but able to
> >>>generate neural signals with the brain which can be measured and
> >>>interpreted as a binary choice.
> >>>This type of interaction differs from standard switch access in two points:
> >>>1. the probability for a correct signal can vary from 0.65 to 0.95
> >>>depending on the user - we thus need response verification in our software.
> >>>2. The maximum rate of communication is 10-20 bits per minute - we thus
> >>>have to reduce the selectable "accessibles" on any screen to a bare
> >>>minimum, and optimize the selection process by using a visual binary
> >>>recursive subgrouping algorithm. (A "direct" or "scanning" selection
> >>>technique, or even a keyboard (to answer Aaron's question) would be too
> >>>inefficient.)
> >>>
> >>>We are using our own neural signal processing software, which is bound
> >>>to a win platform but does not currently offer any accessibility
> >>>features (so sadly we cannot use Gnome which seems to be a wonderfully
> >>>accessible OS).
> >>>
> >>>Given these factors, I thought it best to create a XUL/CPP interface to
> >>>have direct access to mozilla. This allows us to:
> >>>1. present the visual binary subgrouping cue directly on the web page (I
> >>>am using the inIFlasher interface for this - thanks to Joe Hewitt and
> >>>any other contributors for this very useful piece of code!)
> >>>2. access history information for further optimizing link selection
> >>>(place links that are selected often, at the top of a huffman tree)
> >>>3. Keep the "switch interpretation code" platform-independant using
> >>>mozilla's wonderful XPCOM technology, rather than integrating it into
> >>>our win software, making it even harder to migrate to another platform
> >>>in the future.
> >>>(If there are other solutions to 1. or 2. I would be very interested.)
> >>>
> >>>I agree with Bill that in the long run, more sophisticated switch
> >>>'access methods' should be in the assistive technology itself, and that
> >>>this is not really the responsibility of a web browser, but at the
> >>>moment, for our particular application, I am positive that the close
> >>>proximity of our module to the mozilla code base can only benefit its
> >>>users!
> >>>
> >>>Having said all that, I still believe that many standard switch access
> >>>users might see some use in this new interface. I must admit that I have
> >>>never used switch access software and the following would interest me:
> >>>
> >>>1. What is the most efficient method to choose from say, 20 links on a
> >>>page, that current switch access software provides? (with efficient I
> >>>mean: with as little switch presses as possible. ie. a scanning
> >>>interface would be inefficient.) How would a task like this be
> >>>accomplished with the GOK?
> >>>2. Does current software allow for response verification, ie. offer
> >>>"back" options during selection of a link, in case of an error?
> >>>
> >>>Regards,
> >>>Michael
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >
> >
--
Bill Haneman <[email protected]>
This archive was generated by hypermail 2.1.4 : 03/09/04 EST