Direct Jump To Specific Element, Inside Elements List Dialog, and Elements List Enhanscement

[nvaccessAuto]

Reported by tmantv on 2010-03-05 05:07
Currently, while inside the NVDA Elements List dialog, invoked by pressing NVDA-F7, activating any of the hot keys provided for jumping to a particular element's list, E.G. Alt-H for headings, does not move the user directly to the desired location automatically, but instead takes you to the elements radio button, thereby the user needing to press tab to drop in to the list itself.
Reason for automatic focus from one element to another, is so that the person can be more productive, and not have to press the tab key 2 times if they wish to filter a particular list.
If the person wishes to move directly to the list of landmarks manually, they can tab/or shift-tab to the list of radio buttons themselves, if they so choose to do so.

For example, to filter a list of headings with the word you chosen to narrow down to,

1. Press NVDA-f7 to bring up elements dialog.
2. Press Alt-H to jump directly to the list of headings, landing on the first, or nearest heading match found on the page, which shows up in the tree.
3. Press alt-f to filter the list.
4. Press enter or shift-tab to focus the narrowed results found in the list itself.
5. If not desired match, press tab or alt-f to type in a new string, then repeat process til desired.
   This also applies to land marks and links as well.
6. Press Alt-M or enter, to move you directly on to the desired heading, found on the web page itself.

If made in a future release, have controls on web pages be apart of the elements list, via the Alt-C command, listing all control items that are shown on a web page, which could also be filtered with the alt-f command.
For example, names of buttons, check boxes, edit boxes, combo boxes, etc. Then press enter or Alt-A to activate, focused control within element's list, or Alt-M to move to, focused control, while in element's list.

[nvaccessAuto]

Comment 1 by jteh on 2010-03-05 05:32
This ticket actually makes two separate requests: direct jumping to the list and new element types in the list. Please file them as separate tickets in future. Thanks!
Changes:
Milestone changed from 2010.2 to 2010.3

[nvaccessAuto]

Comment 2 by jteh on 2010-11-24 07:02
Changes:
Milestone changed from 2011.1 to None

[LeonarddeR]

I'd be interested in adding more element types to the elements list as well. @jcsteh, is this a feature you guys would accept in a pull request?

[LeonarddeR]

@feerrenrut: Would you be able to give this a priority?

[LeonarddeR]

To clarify, there is work in progress for this in #6131, and we discussed implementation and changes there. However, due to the proposed changes in the pr, I'd like #7328 to be fixed first before I start working on this again.

[fisher729]

Hi.
Any reason that buttons were added to the elements list separately from form fields? I'm curious, as I know that buttons are also listed as form fields.

[LeonarddeR]

@fisher729 commented on 5 sep. 2017 09:53 CEST:

Hi.
Any reason that buttons were added to the elements list separately from form fields? I'm curious, as I know that buttons are also listed as form fields.

When filtering for buttons, you may notice that you will be able to activate them using the activate button, which is dimmed when reviewing form fields.

[fisher729]

Then the question should be asked if when in the elements list, reviewing a list of form fields, wouldn't it be good to have the activate button available. I just think an extra tab for a seperate type of form field is not good. I wonder what other users think.

…

On 9/5/17, Leonard de Ruijter ***@***.***> wrote: ***@***.*****](https://github.com/fisher729) commented on [5 sep. 2017 09:53 CEST](#588 (comment) "2017-09-05T07:53:10Z - Replied by Github Reply Comments"): > Hi. > Any reason that buttons were added to the elements list separately from > form fields? I'm curious, as I know that buttons are also listed as form > fields. When filtering for buttons, you may notice that you will be able to activate them using the activate button, which is dimmed when reviewing form fields. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #588 (comment)

[jcsteh]

A button is somewhat different to other form fields, since it performs an action. The idea is that you might want to be able to list buttons separately. Other form fields can't really be "activated" as such. You can't really "activate" an editable text field, for example. That said, pressing enter on an editable text field does switch to focus mode, so it might be reasonable to do that when the Activate button is pressed. From an implementatino perspective, this should be exactly what happens if we simply allow activation for form fields.