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

[Veli-Pekka TÃtilà <vtatila mail student oulu fi>]

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/

Michael Whapples wrote:
> 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).