Comment 1 by jteh on 2008-07-03 22:57
Similar to #71, this is not as simple as it seems. First, there are a few questions concerning the behaviour you want to see:

• Most "elements" are represented in NVDA's virtual buffer. This includes list items. So, should moving out of the current element simply move out of the current list item, div, span, etc.? If not, this requirement needs to be very specific. Should we then move up the hierarchy and move out of lists, divs (sections) and tables?
• Where should it move? Again, everything is based on elements. I'm assuming you're thinking it should move to the next element after the one just escaped. However, this again needs to be quite specific.

From an implementation perspective, the virtual buffer library itself can currently "search" for nodes, but simply iterating or moving through nodes is actually somewhat trickier. This is partially because the virtual buffer nodes are actually structured in a hierarchical fashion, even though the text is flat.

Comment 2 by vtsaran on 2008-07-07 17:50
I am primarily after practical application of this feature. An ability to skip out of lists and tables would be a good start.
In my view, skipping ut of sections may not be as practical considering how widely divs are used in web 2.0 sites.

Comment 3 by parham on 2010-05-26 14:04
Logically,

Comment 4 by parham (in reply to comment 3) on 2011-01-04 13:34
Is this ticket forgotten? It is really annoying to press down arrow as many times as the number of rows multiplied by the number of column in a table, to be able to get to the end. When tables get big or lists get long, this becomes a real issue. I'm thinking it would be better to implement this feature for a list of particular elements, not all. For example, tables, lists, and textareas. No one would need to go to the end of an input or div or span element, and it's possible to go to the next paragraph using ctrl+down arrow anyway, so it is not as hard as it is made to seem. All needs to be done is to move the virtual cursor to the end of the table containing the current cell and the containing row above it, and in terms of lists, moving the cursor to the end of the list containing the current list element (LI tag).

Replying to parham:

Logically,

, , and tags of that nature should not count, because they tend to be used everywhere, probably in list items too. What I have seen in other screen readers is this:

In Jaws, for example, when you press the greator button, if you are inside a table, you are put outside of it (not to the start of next element, just after the, say, tag). the same thing happens with lists and definition lists. Also, the first or or or should be exited out of, so that when, for example, you are in a list which is inside another list, or in a table which is inside another table, you will still be in the table that appears higher in the document tree (I.E. is the parent list/table of the one you are currently in).

Comment 5 by peter on 2012-02-05 20:10
Hi guis,
I would like to support this idea. Jumping over long list or table is really useful on many websites. I made a simple greasemonkey script which adds invisible separator to the begining and the end of each ul, ol, tr and blockquote and these separators can be used to easily skip long lists and tables. But these separators are announced by nvda which is of course not good in many situations because nvda is too chatty. What do you think about the following idea?
Give the user a possibility (e.g. in configuration dialog) to allow nvda to add special inivisible markings to the page represented in virtual viewer. For example bbefore and after all lists, before and after all tables, before and after all block quotes and so on, and implement hotkeys to skyp to next and previous invisible mark. This can help those of us (happy users of nvda) who would like to skyp long chunks of list items, tables,... and it seems that this is not very complicated to implement.
May be that these marks can be used more intelligently in the future. E.G. it is possible to think about some heuristics to find the main contents of document without aria landmarks definitions and mark it.

Comment 6 by Ahiiron on 2012-02-07 09:45
Yes, I too would like to see this implemented at some point. Nothing too fancy, just a simple move out of main containing element, such as a list. Obviously, it would make more sense to move to the end of the element source, such as the list or table, not just to the end of the current list item/table row/column/cell. In other words, move to the end of any major element you're currently focused in. This would be a pretty big deal, as i use webpages taht have tons of lists and tables, and hitting L/Shift-L is sort of annoying because yo uthen end up at the beginning of another list, thus missnig content, especially in poorly structured pages where headers/landmarks aren't used correctly.

Comment 7 by jteh on 2012-02-09 07:58
As I explained in comment:1, the issue here is that the requirements aren't specific enough. "Major elements" is not good enough, nor is "elements such as lists"; we need specifics. I'm going to say lists and tables for now, since they seem to be the major requests.

Then there is the issue of where to jump. We can't jump out of something without jumping to the next element as someone requested; there is nothing in between. So, I'm going to say that one command will jump to the start of the element and the other will jump to the end. This makes it symmetrical. This also means that if you do it twice, the second time will have no effect; you'll have to move somewhere first.

So, is everyone requesting this feature happy with the requirements I just stated? If not, please be very specific about what you want.

Comment 8 by peter on 2012-02-09 08:05
Yes, that's perfectly enough. And think also about frames if possible.
Thanks

Comment 9 by camlorn on 2012-04-10 01:22
What is the status of this? I really, really want it.

As I mentioned in a ticket I previously posted, nvda actually supports more accessibility apis than, say, jaws (this is sad, given that Freedom Scientific gets paid every time someone wants to use it) and I wish to use it for programming.  In the current setup, viewing the msdn references is nearly impossible because of the tables that have, I kid you not, upwards of 200 rows in some cases.

I'm not sure why we can't just do the following; I haven't looked at nvda's actual code, but do program a bit.

When a keystroke, say >, is pressed, move to the point in the parent node, whatever that may be, directly after the closing tag. When a keystroke, say < is pressed, move to the point in the parent node before the opening tag. Repeating these keystrokes then moves in and out.

The trick after this is simple.  Limit the list to, for instance, table tags. Or frame tags. Or a user specified list.  If you are feeling ambitious, add a second keystroke to do it unconditionally, even for tags that doesn't make sense; in short, the above without limiting the considering tags.  I would recommend regarding only table, frame, and list tags; this is what jaws seems to do, and it works well.  To get this to work, when looking at the tree, you ahve to regard only those tags in question, or you start running into all sorts of fun.  There's also problems with malformed html, especially since what the browser does to it can vary, but that's perhaps another issue and I'm not qualified to talk about this beyond a very, very broad outline.

Clarification: I don't mean regard only one tag. I mean consider all three when looking for the point in question; stop searching when any tag in the list of regarded tags at the same level is found.

This implementation is naive, but should at least provide some specifics to the feature; the main issue here seems to be  lack of highly specific requirements.


Being a power user of just about everything I bother to learn, user-specified list is my favorite.
I'm not as knowledgeable on this as I sound...take it with a grain of salt.

Comment 10 by jteh on 2012-04-10 03:40
It'd be nice to do this in the next few releases.

See comment:7 (and the reply in comment:8), where i stated specific requirements and requested feedback. That's what I plan to implement, so if you're not happy with it, please comment.
Changes:
Milestone changed from None to near-term

Comment 11 by ianr (in reply to comment 10) on 2012-04-10 16:32
@jteh, your requirements sound good to me except that I would also like to add multiline edit boxes.
For instance, an empty multline textbox is easy to move passed but when I type a large message in it, then hit escape to go to browse mode and press down arrow I have to arrow through all the text in it.
Some sharing sites auto populate multiline textboxes and this would be helpful there too.
Thanks!

Comment 13 by sbahram (in reply to comment 7) on 2012-04-10 19:36
Yes, I'm comfortable and in agreement with those requirements. Additionally, I'd like to support the idea of multiline edit fields being subject to being skipped, and reitterate that in nested lists, only the immediate list should be skipped, but if it is hit again, for example, then the parent can be skipped as well. Note, if one need to down arrow or something first before hitting the skip keystroke again, that's fine.

Comment 14 by camlorn on 2012-04-10 19:41
Yeah, mostly. Those requirements do look good. I will say, however, do be careful to make it extensible somehow; I have a feeling this will be popular enough that people (other than myself-I only use it for lists and tables in jaws) will want more.

Comment 15 by Ahiiron on 2012-04-11 16:59
I agree with what Jamie stated in Comment7, and also Sbarham with edit multiline edits. This will be great to have.
thanks.

Comment 16 by mdcurran on 2012-04-25 07:06
Implemented in 1a79718. Current gestures are "kb:shift+," and "kb:shift+." for start and end respectivly. Do these gestures work okay for locales other than English?
Changes:
Milestone changed from near-term to 2012.2

Comment 17 by jkinnunen (in reply to comment 16) on 2012-04-25 10:37
Replying to mdcurran:
Current gestures are "kb:shift+," and "kb:shift+." for start and end respectivly. Do these gestures work okay for locales other than English?

In Finnish locale, shift+, is used for typing a semi colon and shift+. for typing a colon. I think The same applies to Swedish locale as well.

Comment 18 by ragb (in reply to comment 17) on 2012-04-25 10:42
Replying to jkinnunen:

Replying to mdcurran:

Current gestures are "kb:shift+," and "kb:shift+." for start and end respectivly. Do these gestures work okay for locales other than English?

In Finnish locale, shift+, is used for typing a semi colon and shift+. for typing a colon. I think The same applies to Swedish locale as well.

Same for portuguese. Note that there is no big deal with using these key combinations, but the "<->" menomonic does not make much sence for users. In my portuguese keyboard, for instance, "<" is a a key for itself (left to the "z" key). ">" is typed using shift+<.

Regards,

Rui

Comment 19 by parham on 2012-04-25 11:24
What about comma and period then? Would that be different?

Or maybe plus and dash?

Comment 20 by Bernd on 2012-04-25 11:51
What about using < (less) and > (greater) I think this would be quit logical for all.

Comment 21 by erion on 2012-04-25 12:00
I think there is no need to worry. The less and greater than symbols were just based on the default keyboard layout. It is mostly shift dot and comma.
Since the snapshot which contains this update is out already, you could test this to see. Here, it works flawlessly on a Hungarian layout, where its a question mark and a colon. But the symbol does not matter though, only that its shift+dot and comma.
My concern though with these shortcuts is that in every case a nav key on its own would take you to the next element, and with shift itd do the opposite. With shift+dot and comma, however, its totally different.
If possible, I'd change it to dot and shift+dot respectively, to remain faithful to the concept of nav keys.

Comment 22 by mdcurran on 2012-04-25 12:02
Maybe Jamie can answer this better, but I don't believe we can bind to those keys as they would always be decomposed to shift + what ever on keyboards such as English. I could be wrong though.

Comment 23 by k_kolev1985 on 2012-04-25 12:18
hello,

Two observations:

1. Seams not to work for tables. Open the NVDA "keyCommands.html" document and test with a table from there. When I'm in a table and press Shift+Less or Shift+Greater, NVDA says "Not in a container".
2. Shift+Greater doesn't work on a bulgarian keyboard layout. When I press it, NVDA says that there is no previous block quote. But this problem is probably more global and affects other similar commands as well. For example, when the keyboard is switched to bulgarian layout, NVDA's shutdown command (NVDA+Q) doesn't work as it should as well. Actually, when the keyboard is switched to bulgarian layout, NVDA+Dot (from the US layout) executes NVDA's shutdown command and NVDA+Q executes the "Go to the end of the current container" command. Strange, but that's the way it is. I guess that is a issue in the Python's keyboard hooking implementation, because SkypeTalking (witch is also written in Python) has similar issues.

Comment 24 by mdcurran on 2012-04-25 14:15
Do you have reporting of tables turned off? If so I can possibly see why this is broken. I think this can be fixed. However, if you do not have report tables turned off, I certainly can't reproduce the bug. Works fine for me in keyboard commands document in both IE and Firefox.

Comment 25 by k_kolev1985 on 2012-04-25 17:41
Yes, I have turned off the reporting of tables. As soon as I turned it on, the 2 commands started working as they should. This will probably affect navigating to the begining and the end of other types of elements as well, if the reporting of them is turned off. And yes - I experimentally turned off the reporting of lists and the 2 commands stopped working correctly in lists.

Comment 26 by jteh (in reply to comment 24) on 2012-04-25 21:46
Replying to erion:

My concern though with these shortcuts is that in every case a nav key on its own would take you to the next element, and with shift itd do the opposite. With shift+dot and comma, however, its totally different.

If possible, I'd change it to dot and shift+dot respectively, to remain faithful to the concept of nav keys.

I totally agree with this. It is more consistent.

Replying to mdcurran:

Maybe Jamie can answer this better, but I don't believe we can bind to those keys as they would always be decomposed to shift + what ever on keyboards such as English.

If you mean binding to < and >, yes, you're correct. < is always shift+, and > is always shift+. for English.

Replying to mdcurran:

Do you have reporting of tables turned off? If so I can possibly see why this is broken. I think this can be fixed.

One question: should we fix this? If a user has chosen to completely ignore the presence of a particular container, should this command override that? I guess quick navigation commands currently ignore reporting settings, but this one does seem a bit strange to me.

Comment 27 by silverhythm (in reply to comment 26) on 2012-04-26 17:26
Replying to jteh:

One question: should we fix this? If a user has chosen to completely ignore the presence of a particular container, should this command override that? I guess quick navigation commands currently ignore reporting settings, but this one does seem a bit strange to me.

FWIW, I'd like to see it work regardless of the reporting settings. I turn a lot of those off not to ignore them but to cut down on general chattiness. I turn them on when exploring less familiar pages, but I'd still like to be able to use the commands on pages I already know well and have turned off the reporting for.

Comment 28 by ateu on 2012-04-27 01:17
Hi,

The commands doesn't work in chrome tables, only in lists.
Tested with recent releases.
Is it necessary another tycket?

Thanks

Comment 29 by mdcurran on 2012-04-27 02:25
213bd81 allows this to work even if NVDA is configured not to report the element. Re Chrome, probably another ticket is best.
Changes:
State: closed

Comment 30 by ateu on 2012-04-27 09:27
Hi,

No, fixed also in chrome. Thanks!

Comment 31 by PZajda (in reply to comment 16) on 2012-05-10 19:55
Replying to mdcurran:

Implemented in 1a79718. Current gestures are "kb:shift+," and "kb:shift+." for start and end respectivly. Do these gestures work okay for locales other than English?

Hi,

"Shift+," works, but "Shift+." doesn't work for me. I use french keyboard.

I think the problem is to do a ".", we have to press "Shift+;".

Comment 33 by jteh on 2012-05-11 04:34
Mick, thoughts on changing these keys to , (end) and shift+, (start)? I think this should solve the locale issues, plus it is more consistent with the rest of the quick nav keys.

Comment 34 by mdcurran on 2012-05-14 05:06
Keys changed per Jamie's suggestion in 3c68e9f.