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

[Marcus Habermehl <bmh1980de yahoo de>]

Am 26.01.2011 16:09, schrieb Hammer Attila:
> 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.

My new patch would solve this, if it's acceptable by the devels.

> Now right if I seeing only unnamed headings (for example
> vakbarat.index.hu, akadalymentes.sg.hu)?

Currently my patch is using the already existing functions of Orca to
get this informations. For such "special" HTML constructs I will add a
fallback function if the main part is done.

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

In that case the two-step keybinding wouldn't work. But for me it's no
matter.

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

Yes, because the new patch is using the Present methos of the
structural_navigation. All objects are presented only. I think for links
we should go back to the old behavior and open the link.

Joanie, what do you think?

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

That's the same as with visited/unvisted links. It would break the
two-step keybindings.

So, which variant would be more advantageous?

Greetings
Marcus