Re: [orca-list] Structural HTML navigation by lists

[Michael Whapples <mwhapples aim com>]

On -10/01/37 20:59, Marcus Habermehl wrote:
> Am 22.01.2011 12:11, schrieb Michael Whapples:
> > Hello,
> > I very much agree with Steve. We certainly should not use many key
> > presses up for a feature which may or may not be used by some people (I
> > can say for myself I don't make use of such a feature, even when its
> > available to me when using Mac and voiceover, I generally prefer jump to
> > next element of given type or do a search).
> I have to contradict you. Otherwise we would have to put the flat review
> to the debate.

Why are you contradicting me, if anything proving what I mean. In the 
case of flat review, in the ideal world I think there would be little 
value to it. However we don't live in the ideal world, sometimes 
applications are poorly behaved and flat review is the only option. As 
an example I had a plugin for thunderbird which added an icon to the 
toolbar but provided no other way of activating the feature other than 
to click it, therefore flat review was needed to be able to activate the 
functionality of the plugin. Another example of the need for flat review 
is to reread the output in a gnome-terminal window. So there are some 
examples where flat review are needed, lists of links, headings, etc, 
aren't needed, one can get at those elements in other ways as I have 
already described.
>   Just as an example: JAWS has shortcuts for structural
> navigation and separate lists. No one I know and used JAWS, uses the
> structural navigation.
That is jaws in a windows environment, we are on about orca in a gnome 
environment, lets keep to what makes sense for orca. My point here is, 
if an idea is good for orca it will stand up regardless of what other 
screen readers do.

> > Now how might it be done, the treeview is one option, another being the
> > submenu idea. Now how might these compare for usage? Thinking about it,
> > the menu/submenu idea is nice as one could press the key to bring up the
> > menu listing the various types of element (including "All elements") and
> > then the user could easily jump to the appropriate one using the
> > shortcut letter. Its the next bit which may not work so well if using
> > submenus, I don't think GTK menus allow one to type so much of the menu
> > item they want to go to (like you can on the Mac), so meaning the user
> > would have to scroll through the menu to find what they want in the
> > submenu.
> I'm not sure what do you mean. Do you mean something like this: You are
> searching for a link 'Login' and type 'log', or do you mean typing 'l'
> as often as you are at 'Login'?
I mean typing "log" or may be even "lo" if that is enough to get to it. 
The repetition of first letter seems so clunky at times to me, eg. 
helping my father with his windows computer, trying to get to "Mozilla 
firefox" in the programmes menu took so long as there was microsoft 
this, microsoft that, etc, and so took at least half a dozen presses of 
m where as "mo" would have gone straight to it.

> The last one is provided by gtk+. The first one I think not.


> > Now to the tree view idea, I think this does allow filtering by typing,
> Yes it does. But currently the search results aren't spoken. See
> https://bugzilla.gnome.org/show_bug.cgi?id=632058. So the first letter
> search, provided by menus are at the moment more comfortable to the user.
>
> > but I am not sure if there is a nice key stroke in gnome/GTK to go back
> > to parent node of the tree (say I had gone into links and was quite a
> > way down the links, I don't think there is a key stroke I could use to
> > go back to the links node which is expanded, may be because I realised I
> > found it wasn't a link I need but a button).
> >
> > If I am wrong about the jumping back to parent nodes in a tree view then
> > I think the tree view may be better, otherwise I get the feeling the
> > menu idea is better (IE. if I know the text of what I am looking for
> > then I could do a standard search for it).
> I've searched in the sources of gtk+ and found in gtktreeview.c this:
>
> gtk_binding_entry_add_signal (binding_set, GDK_BackSpace, 0,
> "select-cursor-parent", 0);
>
> And it works. Backspace brings me back to the parent tree node. I think
> this is what you mean.
Seems like backspace does what I mean, its I didn't know of that, 
possibly its less discoverable than the technique of left/right to 
expand and collapse nodes and left takes you to the parent.