NVDA should provide ability to navigate out of HTML elements in virtual buffer

[nvaccessAuto]

Reported by vtsaran on 2008-06-25 21:44
Users should have ability to navigate out of elements such as lists, tables, sections etc, with a single keystroke. I believe, this should be easily achievable with the new virtual buffer library.

[nvaccessAuto]

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.

[nvaccessAuto]

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.

[nvaccessAuto]

Comment 3 by parham on 2010-05-26 14:04
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).

[nvaccessAuto]

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

[nvaccessAuto]

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.

[nvaccessAuto]

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.

[nvaccessAuto]

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.

[nvaccessAuto]

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

[nvaccessAuto]

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.

[nvaccessAuto]

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

[nvaccessAuto]

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!

[nvaccessAuto]

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.

[nvaccessAuto]

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.

[nvaccessAuto]

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.

[nvaccessAuto]

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