Re: [orca-list] Structural HTML navigation by lists
- From: Marcus Habermehl <bmh1980de yahoo de>
- To: orca-list gnome org
- Subject: Re: [orca-list] Structural HTML navigation by lists
- Date: Sat, 22 Jan 2011 21:32:31 +0100
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. Just as an example: JAWS has shortcuts for structural
navigation and separate lists. No one I know and used JAWS, uses the
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'?
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,
And it works. Backspace brings me back to the parent tree node. I think
this is what you mean.
On -10/01/37 20:59, Steve Holmes wrote:
We've had the comparison issues between screen readers in the past. I
don't want to see Orca implement something just because Jaws has it,
nor do I want something to be implemented like jaws just just because
people in windows use jaws. I for one, don't do jaws and have no
intentions of doing so. If it just so happens that a feature is well
implemented in jaws, then do it; otherwise, if there is a better way,
I would rather see that instead. In the case of all these lists for
different HTML widgets, I think the treeview approach wouldn't be so
bad but at the very least, I like the idea of a two letter command to
pop them up. this way, you don't lose so many hot keys right off the
bat for a single feature. The first letter of the two-letter command
could open the single dialog for HTML widgets which could actually be
a treeview. Then the second letter would corespond to the types of
elements we now have for structural navigation but also take you to
the matching node in this tree. This way, if one didn't know all the
possible element types, you could brows this treeview and subsequently
learn the shortcuts to get to these nodes directly in the future.
So this way, you have the treeview approach but commands to take you
to separate lists.
Oh, I also see little value in differentiating between visited and
unvisited links I would just soon find the next link regardless of
visited or not. Actually, with my suggested deal above, it wouldn't
matter if you included these separate lists. After all, it might as
well be consistent with the available structural navigation commands
we now have.
Hope this all makes sense.
On Fri, Jan 21, 2011 at 02:33:51PM +0100, Marcus Habermehl wrote:
Am 20.01.2011 14:15, schrieb Geoff Shang:
I'm very new to Orca, so will keep my comments to a minimum. But you
may want to look at what's been done in NVDA. You only have one dialog
box there and select the type of element to look at. You can also
in a search string to narrow down the list.
I wouldn't take the way of NVDA as a good example. NVDA lists only three
types of objects, one of which was always empty in my tests.
We should prefer commercial screen readers such as Jaws or Hal/Dolphin
as an example. I think they are the best known on Windows.
Firstly, the developers will have something in mind for their solution
and on the other a similar behavior makes it easier to change between
Windows and GNOME.
Both have separate lists. Hal/Dolphin represents those lists in one
window but distributed to different tabs in a notebook. JAWS on the
other hand, uses different windows.
] [Thread Prev