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

[Marcus Habermehl <bmh1980de yahoo de>]

Am 24.01.2011 09:32, schrieb Michael Whapples:
> 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.

Michael, I will contradicting because of your arguments.

You use the flat list and it's okay for you that this requires a lot of
shortcuts.

You don't use the lists and it's not okay for you that they need a lot
of shortcuts.

It's okay that we talk about it. But I do not agree that the preferences
of other users are ignored completely.

Perhaps the people I know too inflexible. I do not know. But when they
tried to work with Orca, they have problems without these lists. And I
think "there are too many shortcuts" simply not a valid argument against
it. Sorry.

> >   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.

To me it's not about comparing Orca with JAWS or GNOME with Windows. In
the case of lists, it's about how a person navigates through web pages.
And since it does not matter whether with JAWS in Windows or Orca in
GNOME. There are simply users who mainly use these lists. That should
not be ignored.

> > > 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.

As I know this is only possible with treeviews, not with menus.

> > 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.

Backspace is also used in Nautilus to move to the parent folder.
However, I would have never thought of it. Maybe it should be included
in the tutorial messages. Or would it be too long? I can't assessing it
because the German tutorial messages are far too long. :-(

Greetings
Marcus