Re: [orca-list] Dragging and dropping with orca, KBD Interface Critique

[Michael Whapples <mwhapples aim com>]

Here are some of my thoughts on this.

In most cases where dragging and dropping is needed (because of no
keyboard commands for the control) it normally comes down to a poor
implementation, particularly when it comes to accessibility. In these
cases its normally imaginable that there could be keyboard equivilents
to do what the dragging and dropping is doing whilst allowing those who
don't want to use a keyboard to click to their hearts content. As an
example, in sound editing software, when the wave view control gets
focus you could have it that you can move the initial marker (the front
of the highlight, with left and right, and move the right edge of the
highlight with shift and cursor left and right. In this example, what
should be spoken and brailled for such a control, well it could give
current position of moved marker (left or right edge of highlight) and
whether it is sitting on any other marker such as a track marker. You
may imagine where I am now heading, yes you could use cut, copy and
paste for the highlight where you may normally drag and drop that
selection.

I can think of a few cases where possibly keyboard shortcuts may be
difficult to implement, although may be possible, but these uses tend to
be very visual in the operation that is being carried out and would be
extremely, if not impossible, to represent via braille or speech due to
the highly graphical nature of the material which is being operated on
(eg. in image manipulation, could you make a drawing package fully
accessible even if the keyboard shortcuts were there? What should the
drawing area speak to the user?).

One thing with linux, is that a lot of the functionality is provided
from an underlying library, and normally there are various front ends
for it (eg. GTK or QT interfaces), and as the text console is still
quite used in linux, sometimes if the graphical interface is
inaccessible you may just have to roll up your sleeves and get your
hands dirty and use the text console. May be in suggesting this I am
foolish on such a list, but I think the text console is normally much
more accessible, and only use gnome where text based systems fail (eg.
those awful websites that near enough require you to use a browser they
want you to use and firefox ends up being the only accessible Linux
solution for them).

From
Michael Whapples
On Wed, 2007-05-30 at 16:56 +0300, Veli-Pekka Tätilä wrote:
> krister kristersplace ws wrote:
> > On 29 May 2007 at 22:39, Henrik Nilsen Omma wrote:
> >> How will this differ from cutting (Ctrl+X) and pasting (Ctrl+V)
> >> though? What could you do with drag and drop that you cannot do with
> >> cut and paste?
> > There are situations, such as in certain audio editing and music
> > software wher you are to manipulate widgets and such and in that
> > case, you can't copy/
> > paste.
> Exactly, and not just audio apps iether. Think of diagram editing or 
> anything remotely graphical that's based on direct manipulation. Any 
> cursorless area in which the user has to use the mouse to select stuff 
> presents similar problems. many readers implement D&D, that's drag and drop 
> not dungeons and dragons <ssmile>, as marking the source object for dragging 
> and the destination object for dropping. But another equally useful thing 
> would be the ability to drag with the left or right button an arbitrary 
> vertical, horizontal or circular amount measured in pixels. This kind of 
> dragging is used to manipulate controls like knobs, which is not about 
> dragging one object to another.
> 
> Yet another thing, in which at least the MAc requires drag and drop, is 
> lists in which you have to re-arrange items by preference e.g. preferred 
> languages on the Web. In addition to screen reader based D&D, I've seen 
> up/down buttons and keyboard interfaces for moving e.g. alt+arrows.
> 
> And howabout re-arranging and re-sizing columns in what people call tables, 
> multi-column list views or deetails views depending on context? Windows does 
> not provide a keyboard interface for any of this in the control directly, 
> and if the Linux folks have been borrowing without thinking, I suppose 
> neither does Gnome. I honestly think MS made a mistake with that particular 
> control and having to suffer from it ten years in various apps, it is 
> extremely annoying to see the same poor keyboard interface being duplicated, 
> say in OS X. Sory, I just feel strongly about this, and wanted to get the 
> point across (ho offense ment, <smile>). I honestly hope Gnome and all the 
> rest of the Linux GUis do better keybordwise. So, the question, can you 
> re-arrange columns in a multi-column list from the keyboard in Gnome? In 
> WIndows, screne reader based D&D or duplicating the functionality in a 
> dialog box (think OE or Explorer's choose columns) are some of the 
> work-arounds.
> 
> Back to mousy things, though, the fundamental problem is at the app end, 
> though, failing to provide a keyboard interface for custom controls like 
> knobs, sliders, points in graphs etc...  I see no reason why knobs could not 
> have the same keyboard interface as sliders do: up/right for small 
> increment, pg up/down for larger units and home/end for  reaching min and 
> max. Its just that once things get custom enough, people stop payihng 
> attention to keyboard interfaces, which is sad. And its quite common that 
> you even cannot type in or see values directly, because the original thing 
> they are emulating or modelling could not do that either, which annoys the 
> heck out of me. It happens an awful lot in the synth plug world for no real 
> reason.
> 
> How is the Linux music software in this regard? Most Vst plugs and hosts are 
> keyboard nightmares to say the least, and I'm afraid this mousy philosophy 
> might have carried over to LInux as wel. How is ardour, for example, which 
> should be GTK+ 2 based and thus potentially accessible? a friend of mine has 
> been hyping that one a lot lately. He also runs VST plugs under WIne but no 
> ORca there, of course.
> 
> > want to put an audio loop on a track you have to drag it there.
> Not only that but you have to drag, too, when you want to extend a pattern. 
> from a keyboard user point of view, this makes no sense at all. I mean, if I 
> know I want 10 times pattern x, 12 times pattern y and 10 times pattern z, 
> that's a lot of D&D which can be very slow full-sscreen magnified. It would 
> be an order of magnitude faster for me to simply supply a repeat count.
> 
> -- 
> With kind regards Veli-Pekka Ttil (vtatila mail student oulu fi)
> Accessibility, game music, synthesizers and programming:
> http://www.student.oulu.fi/~vtatila/ 
> 
> 
>