Re: Keyboard navigation on RISC OS?

On 6 May 2008 David <nospam@xxxxxxxxxxxxxxxxxxxxx> wrote:
Getting away from the last thread in the hope of a better tempered
discussion on this one subject.

I can't see how this could be done except by emulating mouse movement
by a combination of key+cursor keys to position the pointer, and then
represent the three mouse buttons by some key combinations (didn't the
A4 do this?) and this would be only of limited use except where a mouse
wasn't at all practical.

Or do the proponents want some other model of keyboard navigation? If
so, I'd welcome an explanation of what is wanted and how it would
actually impact on the RO desktop.

Well its not easy to bolt on after the fact when the OS doesn't
support it, and applications have been written with no regard to
such things as the logical ordering or controls. Indeed apps may work
against you by claiming key combinations you want to use for
navigation as hot keys.

Even in Windows which has been designed with keyboard support from
the start, due to lack of consideration by application designers there
are large gaps in support which means you can't work certain non
standard controls or navigate to some window panes from others.
Therefore in our screen reader we have to implement a virtual focus to
take over from the OS one and allow you to move to certain places. In
some cases we just can't get enough information from the OS about a
window, and have to supply supplemental "mapping" information that
associates a rectangle with a window with a certain type of control.

In RISC OS we would have to implement this virtual focus system as the
OS doesn't have one. There are three basic parts to it.

1) To allow you to move between Windows. Including an Alt+Tab style
switcher between applications, and Ctrl+Tab style jumps between
the main area and any supplemental panes. RISC OS applications
may have obvious panes to look at, but to the Wimp they are
completely separate windows, which the application just happens
to move or resize in when another window is altered by the user.

2) Movement within dialog windows Betty icons. This needs to
work logically so the arrow keys take you to the icon in the
desired direction and also the associate next/previous in
groupings like radio and on/off controls. Which is far from
straightforward as a lot of dialogs are designed with no regard
to icon ordering, as they are only oriented to control from the
mouse.

3) Working icons with the keyboard, which involves activating buttons,
on/off boxes and radio icons, pop up menus, sliders, up/down icons.
Those are fairly straight forward, but with a lot of drag and drop
functionality in RISC OS, you need to replace this with cut & paste
clipboard support, to an extent far greater then even Select 3+
offers. There is the huge issue of user drawn icons some of which
may appear to be close to standard ones, but no knowledge may be
deducible from them. Other user icons may be something completely
different and require complex navigation such as list and tree
controls.

It would be a big challenge to implement this either an external
application such as a screen reader, or buy building it directly in to
the Wimp. You could probably get 90% of the way there quite easily,
but as someone mentioned the remain 10% of edge cases would take a
huge amount of effort. But then unless we are talking about screen
reader users who can't use a mouse, most people would be OK reverting
to he mouse in certain circumstances.

---druck

--
The ARM Club Free Software - http://www.armclub.org.uk/free/
The 32bit Conversions Page - http://www.quantumsoft.co.uk/druck/
.

Loading