Re: [orca-list] Semi OT: Dragging and dropping with orca, KBD InterfaceCritique

[Michael Whapples <mwhapples aim com>]

As some of this is slightly of topic, I will try and keep it short, but
I think while the idea of accessibility in general is not the purpose of
this list, it certainly may bring up some useful points relating to
Orca.

When using the command line, I normally don't use orca in the
gnome-terminal, I switch to a proper text console and use speakup for
that. I just feel with all the other features of orca for working in a
GUI, it is simpler to work in a proper text console with something
really designed for the command line. While my view may differ on amount
of command line usage to some, I may not quite go as far as some (look
at edbrowse, www.eklhad.net/linux/app), I prefer the 2D layout of
something like elinks.

Regarding the visual cases where keyboard shortcuts don't have value for
screen readers, I was more thinking of photo editing, or to use a
windows example paint. Graph accessibility (data graphs) would be
something I would like to see happen.

As for whether orca should have a drag and drop function as the
situation as it could be doesn't exist and dragging and dropping may be
the only option, I have mixed views. If orca does have the feature,
developers don't feel that keyboard shortcuts will add to the
accessibility of their app as orca allows us to drag and drop, but if
orca doesn't have it then we are stuck in the mean time until (if ever)
such a situation happens. Now yes I know as a user, the first isn't
really satisfactory, keyboard shortcuts would be better than using an
orca drag and drop feature, as in some of these cases if the keyboard
navigation doesn't exist then the information for orca may not exist.

Also your comment about the accessibility API, yes all communication
from the app should be transported to orca through the accessibility
layer, we don't want to have apps tied to one screen reader, what about
LSR, or even if something better than both of them comes along. Also
accessibility APIs could be used for app testing, which would test the
API even more.

From
Michael Whapples
On Wed, 2007-05-30 at 18:22 +0300, Veli-Pekka TÃtilà wrote:
> Hi Michael,
> You have some very good points in there.
>
> Yes, the fact that most keyboard inaccessible controls that require D&D 
> could simply have a keyboard interface is what I was after, too. My point is 
> that, even in the LInux world, such accessibility blundres don't seem to get 
> fixed instantly at all, so it would be still highly useful to have the D&D 
> functionality in Orca, too, as a reader specific work-around.
>
> But could not the accessibility API support things like that screen reader 
> independently? At least in the MS world the same lib is used for 
> accessibility and GUI testing, meaning that you can also interact with 
> controls programmatically.
>
> About sound editing, actually Sound FOrge here in the Wintel world has much 
> the keyboard interface and screen reader support you go onto describe. You 
> do have to switch the selection between the two ends but other than that its 
> great. I'm still missing the ability to select 10 % of the viewport by page 
> up/down in Audacity. It works in Sound Forge, after all.
>
> You're right that many apps that are truely based on direct manipulation and 
> graphics would not really benefit from a keybord interface. But even some 
> things that are conventionally thought of as graphical could be, if you'd 
> like to rethink, made accessible. One such thing is a graph with draggable 
> points. There's no reason why you could not manage the points in a list 
> view, for example, and mentally interpolate as needed.
>
> Lastly, this is geting a bit odd but true Linux still is a command-line OS 
> and no matter how many graphical front-ends will be written, it will be a 
> command-line OS. Thus it pays off to learn that command-line. Which reminds 
> me, how well does it work in Orca?
>
> But in that context I've found that I'm not a command-line guy in general. 
> Apparently it is quite possible to enjoy programming, text processing and 
> scripting (think, Perl, Ruby and Regexp) while still wanting to do things 
> graphically, when wearing your user hat. I'm like that. Its a testament to 
> the ease of use and relative power of a GUi system that even some people who 
> handle it as text from the keybord find it more enjoyable than the 
> command-line.
>
> I'm sure I'm in the minority but that's how things stand. let's take a 
> concrete example like file navigation. WHen I do it graphically I can 
> navigate via type ahead and get instant spoken feedback of the currently 
> selected item. WHen you add the ability to type in multiple letters, wild 
> cards and searching by extension plus sorting, its very efficient. Where as 
> when i use ls and cd to get around it just feels clumsy, much more error 
> prone and a lot slower, too, even though I'm a touch typist. My sighted 
> friends tell me multi-item file auto-complete and the smart guessing that 
> ZSH do help immensly but both are much quicker to scan visually than they 
> are using speech.
>
> But Hey, I'm getting OT, so if this gets much more OT, let's move it 
> off-list, right?
>
> -- 
> With kind regards Veli-Pekka TÃtilà (vtatila mail student oulu fi)
> Accessibility, game music, synthesizers and programming:
> http://www.student.oulu.fi/~vtatila/