RE: mouse alternatives

Jonathan Chetwynd wrote:
| 
| shift-alt-click mouse move is hardly a gainly exercise for any 
| individual,

I don't think you'll get any disagreement there.


| is there a good reason why arrowkeys aren't used?

I can't think of a good reason why arrowkeys shouldn't be used. In fact,I've
advocated that for a while [1][2]. In several of my apps, I've used
arrowkeys to move the selected object around on the screen, which is good
for all users, physically challenged or not.

However, that doesn't mean that that's the only possible use for arrowkeys.
In other apps, I have used them to pan around the screen, or to change the
focus selection. Other authors may wish to use them to change values such as
brightness/contrast, or sound volume, or to move the mouse cursor around.
There are any number of possible uses for arrowkeys. 

Correct me if I'm wrong, but it seems that you wish them to be defined
exclusively (or at least by default) for the use of moving the pointer
cursor around, for consistency of navigation for accessibility purposes. I
don't think that that would necessarily be a successful strategy. If the
arrowkeys were unable to be remapped to other ends, authors would be
extremely frustrated (and rightfully so, I think); if it were merely the
default action, any author who wished to use the arrowkeys for would break
that consistency. Still, having it as a default, overrideable action would
be better than nothing, I reckon; at least then, some content would have
"mousekeys" by default. But then again, as you said on irc.freenode.net#svg,
this is already an option in most Oses; that being said, I personally have
no objections to having it defined as the default SVG key mapping. 

However, it does bring up an interesting issue, which is that currently (as
far as I've been able to find), there is no way to exert pointer control
other than the mouse (except at the OS level, that is). I agree that this
would be really useful (security issues aside*). I'm not sure it's something
that SVG should define (seems like maybe a CSS-UI issue?), but then again,
SVG is defining other things that are not graphics oriented, such as
sockets; since, as we have both pointed out previously, SVG is very
different to HTML in its interface needs, so maybe it could provide a way to
at least map pointer-movement to arrow keys. Would that be useful?


| defining this as an OS issue isn't that helpful.

I didn't define it as an OS issue. You did. [3]


| OS accessibility has primarily been concerned with typing 
| accessibility, a rather tight-knit group of editing applications, many 
| of which are helpful to those with low vision.
| 
| SVG offers a very different interface, one that isn't necessarily type 
| driven, but more likely GUI driven.
| This means there is some overlap with current GUI accessibility, and 
| there is potential for far more.
| However unless this is planned early on, it is likely to go awry in a 
| very similar manner to access keys.
| This eventuality won't enable many users

I think a very useful way to proceed would be to mandate accessibility is to
encourage authors of sXBL widgets to take it into account. In fact, I
suggest that the WG puts explicit language in the sXBL Spec to that effect.
If widget-authors build accessible controls, those who use those widgets
will inherit the accessibility, almost as if it were at the UA level, and
each accessibility feature will make sense for each widget. I think that
this is a realistic propogation strategy. 


* If script control of pointer movement is allowed, there is the threat that
an author could do something that pops up a security warning, then use
script to move the mouse over and permit the security violation.

[1] Win/IE only: http://schepers.cc/walkingtalkingsvg.html
[2] http://schepers.cc/BAM/#section7
[3] http://svg.jibbering.com/svg/2004-10-11.html#T15-20-30


Regards-
Doug Schepers

Received on Wednesday, 13 October 2004 18:35:59 UTC