Re: GNOME A11y: where do we need to improve? (Want input by 25-Jan)

[Francesco Fumanti <francesco fumanti gmx net>]

At 9:21 AM +0000 1/25/08, Steve Lee wrote:
>  > I could for example imagine the following plug-ins:
> >  - a basic onscreen keyboard plugin
> >  - a dwelling plugin
> >  - a word prediction plugin
> >  - a switch access plugin
> >  - an ui grabbing plugin
> >  - a speech plugin
> >  - ...
>
> I like this, though a dwell and speech (and possibly prediction) are
> better served by integration with general purpose ATs.

I don't understand exactly what you mean by general purpose ATs; what 
would be the non general purpose ATs? In fact, in my view the 
fonctionalities of the "plugin" would be available sessionwide.

And now the following occurs to me: should I not say systemwide 
instead of sessionwide!? For example what about GDM? Say a user 
installs an AT; should that same AT not automatically be available at 
the login-screen, but not necessarily activated.

I could imagine following scenario: User Paul gets an account on a 
machine. As he is a user that can only move the pointer, he needs an 
onscreen keyboard and dwelling. Consequently, someone installs the 
onscreen keyboard plugin and the dwelling plugin in Paul's session. 
By installing the onscreen keyboard plugin, a menu automatically 
appears at the GDM login screen that user Paul can use to start the 
onscreen keyboard at the login screen. By installing the dwelling 
plugin in the session, a dwellable spot appears at the login screen 
that user Paul can use to start dwelling (obviously, Paul is not able 
to start dwelling by a menu since he cannot click; that is why the 
dwelling plugin has to install the spot or some other thing that Paul 
can use to start dwelling).
Say user John, that uses the same machine, does not need any AT. He 
sees that new AT tools have been installed; but he can simply ignore 
them since they are not running by default.


Does a plugin have to announce itself to the session? If that is the 
case, I would suggest that the plugin should not only announce itself 
to the session, but also to gdm. I suppose that this would require 
the cooperation of gdm (hi Bryan ;-) ) and the cooperation of the 
plugin writer to ship the necessary things (among others the spot for 
gdm) for the gnome session and for gdm.


For the moment I don't know whether such a modular architectures with 
"plugins" makes also sense for the other ATs available.


The scenario presented here is from a users standpoint; but should it 
not be the starting point of the discussions on what needs to be 
done!?



> Someone
> suggested a calculator plugin that evaluated numeric expressions,
> rather like prediction.

Do I get it right: the suggestion is to use a numerical computation 
to find the completion and prediction word? I am curious: Is there 
any theoretical model supporting the suggestion?


> A script plugin would be useful for power users.

What kind of scripts are you talking about? Does the script provided 
by an application (or plugin) not depend on what that application 
expects?

Supposing, we have plugin A that has a cli and thus understands shell 
scripts. We also have plugin B that requires perl scripts (I suppose 
the scripts understood by an application depends on what kind of 
scripts it has been programmed to understand.)

What could plugn C, the script plugin do?




>  > Maybe another word concerning osk-ng: the intention is to make it
> >  work on multiple platforms. Could you please explain to me the reason
> >  for making it cross-platform?
>
> Being platform agnostic (like Mozilla) means more users can be reached
> using the applications that they prefer.

Will (for example) Windows user even look for free software? I don't 
know, but I assume most will not. I fear that they have the reflex to 
walk into a shop and buy.



> In addition most users are on
> Windows and being cross platform reduces the barriers to migration to
> Linux.

I agree that it will make the transition easier, but having the same 
application will probably not trigger it. There are so many 
applications on (for example) Windows, that having a few applications 
that are the same will not make much difference. (Though AT might be 
a special case.)

Priority should (in my opinion) be given to make the switch possible 
for users that want to switch, by providing them the AT they need. 
And if it is of outstanding quality, it might even attract new users 
who learn about it on specialised forums and lists.
(Besides AT, there are also other things that can hinder the switch, 
for example years of emails stuck in a client that cannot be moved 
properly to gnome,...)

Of course, if there are enough resources to make the product 
outstanding and cross platform, it will be better. (If making it 
cross platform requires only little more resources, it might also be 
worth doing it; but again: it should not be at the expense of the 
quality of the product.)

However, I want to remark that I am not an evangelizer; I don't know 
what makes users really switch; so I might also be wrong.



> And there are
> mobile platforms and the Ultra Compact PCs (e.g. eeePC). These look
> exciting from the point of view of portable communications devices
> (AAC). The increased presence of Linux in these applications means
> there is less distance between platforms. For example I have a
> Linux/Mozilla based Nokia n810 and plan to have a play with it in this
> area.

Incorporating these into the development of AT does make sense as it 
is about the creation of new solutions.


Best regards

Francesco