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

[Hammer Attila <hammera pickup hu>]

Hy,

Marcus, thank you the test patch.
My experiences:
 because this patch generating more lists, I see little speed 
performance slowing for example the vakbarat.index.hu, www.oc.hu 
webpages, but this is real because more objects presenting both two 
lists if it is awailable. Oldest time I think the list generation time 
this webpages is 3 second, now 10 second for example with 
vakbarat.index.hu webpage, I not remember now the last speed result with 
the #620331 bugreport last awailable patch.
For example now the www.oc.hu webpage with containing lot of elements 
this time period is 14 second.

The answers your questions:
Because in list mode you wrote not possible determining the context with 
separators, separators is not need.

"I do not know how important for you it is to distinguish between
headings. The patch currently only lists headings on generally. Should
there are still entries for the different levels, too?"
I think no, enough a general list with containing all headings.
Now right if I seeing only unnamed headings (for example 
vakbarat.index.hu, akadalymentes.sg.hu)?

"The links are in the current list summarized below links and again
classified separately under visited and unvisited links. The distinction
makes sense in the structural navigation. Does it makes sense in the
list, too?"
This is not easy to answer. I think general list is better, but possible 
another users like this method.
If need the distinction, perhaps better moving the unvisited and visited 
menu groups below the links submenu, before the paragraphs. An example 
webpage with demonstrate this is www.origo.hu/hirmondo.
I see an interesting problem with links submenu related:
If only one link have a mnemonics (for example only one link beginning 
with o letter), the link is not opening if I press the o key.

"Same question for the form fields. Which are summarized below form
fields, and again classified separately under the type."
Better I think doing future a separate shortcut with doing filtered list 
for form field elements. For example, if the user need only check boxes, 
enough to press Orca+Ctrl+x.
But if need distinguish form types this menu widget, need doing below 
the form fields submenu with a "form fields by type" submenu and put 
different form fields elements with this submenu. Demonstrate this 
problem with www.google.com webpage. In main menu level seeing a 
"buttons" submenu, "entries" submenu and a "form fields" submenu.
Better order with top of main menu related:
"form fields" (when the user pull down this menu, possible see all form 
fields)
"form fields by type" (when the user pull down this menu, possible see 
form fields with a type ordered submenues).

Treeview or new submenu widget?
Both two method are interesting and some time useful. With treeview are 
big advantage to possible letter filtering, but if not fixed the 
treeview search related Orca bug, this possibility is not usable.
I accept both two method.

Attila