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

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]