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

[Marcus Habermehl <bmh1980de yahoo de>]

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. Just as an example: JAWS has shortcuts for structural
navigation and separate lists. No one I know and used JAWS, uses the
structural navigation.

> 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'?

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.

> 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
> > some
> > 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:
> > > > Hi,
> > > >
> > > > 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
> > > > enter
> > > > 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.
> > >
> > > Greetings
> > > Marcus