Comment 1 by kevinchao89 on 2011-11-15 22:14
via @sinabahram the reason I'm asking, besides the obvious, is that it would greatly help read matrices when layed out in tables.
Confirmed and agree with enhancement request and think it would be very useful.in document, spreadsheet, and web browser.

Comment 2 by jteh on 2011-11-15 22:58
Please be more specific. Control+alt+downArrow moves down to the cell in the next row, control+alt+rightArrow moves to the cell in the next column, etc. Your description provides absolutely no information as to what you're requesting beyond this. Please provide a thorough explanation, as well as examples and use cases.

Comment 3 by sbahram on 2011-11-15 23:46
I'm refering to keystokes that allow one to hear the whole row or the whole column when one navigates up/down or right/left. This would facilitate the reading of a matrix, for example. It would also allow for the reading of content in forums where the bodies of messages are organized, in some forums, in a column, where the date/to/from information is all in a separate column or columns.

Comment 4 by jteh on 2011-11-16 00:33
Can you clarify the forum example? I assume you mean that there are multiple rows for the body of the message, but the body is all in one column?

Comment 5 by sbahram on 2011-11-16 01:26
Exactly. So, in gaming forums or other tech oriented forums this happens sometimes where all the from/to/date stuff is in one column, you have another for avatars/profile images/what not, yet another for usernames/subscription times/ranks, and then the bodies of the messages. So, with a single keystroke one could read all the content in serial order.

Putting that aside, and going back to the matrices example, I already know of a professor who is planning on offering a course in which matrices are featured heavily. So, he wishes to use a format for displaying them in such a way that they are visually pleasing but usable by his blind students.

Examine the following matrix:

1 2 3
4 5 6
7 8 9

If we represent the above as the following, and here's to hoping my html won't get stripped out, and will instead get propperly escaped:

Then row by row, column by column, and most definitely, the existing cell by cell, navigations all have their place and make that matrix a dream to navigate via audio.

Comment 7 by jteh on 2011-11-16 01:41
It's worth noting that if we do this, you will still hear the row/column coordinates as you are reading the column/row, just as you do when you navigate by cell.

How important is this to you (as opposed to "nice to have")? I understand that it is convenient. However, the existing cell navigation already allows you to quickly read a row or column by holding down ctrl+alt and repeatedly tapping the appropriate cursor key.

Comment 8 by sbahram on 2011-11-16 03:45
In the above listed matrix, what I would like to hear when pressing next row, versus priar row is

1,2,3

4,5,6

7,8,9

or, if i press priar and next column, to hear:

1,4,7
2,5,8
3,6,9

So, let's say we want to find out whetehr the following matrix is in row eshelon form:

3,0,2
0,1,2
9,2,0

Now, it's obvious from the above that the top two rows have to be switched, and it was trivial for me to determine that by simply reading that matrix by rows. Using the arrow keys would have taken takes a moment to go do it that way, about 3 times longer.

So I think there's a huge performance increase here. I think this performance increase scales quadratically with perportion to larger tables e.g. 4x4, 5x5, 6x6. Taking 6 keystrokes to explore a 36 cell table, instead of 36 of them is a huge timesaver. It also makes things possible that were not possible before due to working memory constraints and temporal proximety, etc. etc.

Now, if you're saying that the current cell would still get read after the requested column or row, I find myself, as a user, asking, but why? It's simply a row based command, why does the current cell have to be read? If i want the cell to be read I'd use the keystrokes for moving up/down/left/right between cells instead of up/down/left/right between rows/columns respectively.

Comment 9 by jteh (in reply to comment 8) on 2011-11-16 03:56
Replying to sbahram:

Now, it's obvious from the above that the top two rows have to be switched, and it was trivial for me to determine that by simply reading that matrix by rows. Using the arrow keys would have taken takes a moment to go do it that way, about 3 times longer.

Longer is an ambiguous term, though. If you press the keys fast enough, it'll be almost as fast. I'm guessing you're referring to the necessity of having to think of pressing those extra keystrokes (which is a fair point).

Now, if you're saying that the current cell would still get read after the requested column or row, I find myself, as a user, asking, but why? It's simply a row based command, why does the current cell have to be read?

NVDA always speaks information changes as they are encountered according to the user's config so that you know where these changes occur. For example, if you are reading a line, it will always read the links in that line. By the above logic, reading a line shouldn't read the links contained in that line. Doing otherwise for different commands introduces inconsistency. If the config says "report table row/column coordinates", they should always be reported. This is both an implementation and a usability issue. What you could do, however, is disable reporting of row/column coordinates, and these new commands would honour that setting. Is this acceptable?

Comment 10 by sbahram on 2011-11-16 04:06
You say that longer is relative, but actually, if you measure it out, it's not. If we take the cost function to be:

c(n) = cost in keypresses perportional to n cells in the table

Then without keystrokes for row/column navigation, we have:

c(n) = n

Whereas with row/column, we have:

c(n) = sqrt(n)

Yes yes, the above assume a square table, and all that, but it's litterally one square root's worth of keystrokes. That's not one or two key savings here, that's a figurative boatload of 30 keystrokes being saved when dealing with a 36 cell, simple 6x6 table.

Ok, to address your point on event driven information readout rules. You said table coordinates, so i'm guess this means 1,2 indicating i'm in the first row, second column. I would obviously turn that off, but it sounded like, from your previous comment, that you were saying that the contnets of index 1,2 would get read out, so if I was on the first row of the keypad matrix, and let's say i was on the 2, and i hit the next row keystroke, I want to hear: "4,5,6", and it sounds like you were saying that I'd hear "4,5,6,5" because 5 would be the logical place for my cursor to land after moving down. If that's in fact the case, I think that could confuse users into possibly mistaking the table to have an extra column's worth of data, because they'd hear 4 numbers instead of 3.

Comment 11 by jteh (in reply to comment 10) on 2011-11-16 04:11
Replying to sbahram:

You say that longer is relative

Not quite what I meant. I mean that the extra time consumed depends on how fast you press the keystrokes.

but it sounded like, from your previous comment, that you were saying that the contnets of index 1,2 would get read out, so if I was on the first row of the keypad matrix, and let's say i was on the 2, and i hit the next row keystroke, I want to hear: "4,5,6", and it sounds like you were saying that I'd hear "4,5,6,5" because 5 would be the logical place for my cursor to land after moving down.

Ah, no. I was referring to table coordinates. As long as you're happy with turning those off, that's fine.

Comment 12 by sbahram on 2011-11-16 04:13
Definitely happy with turning those off, for sure. As for the relativeness of longer, yes I agree that those keystrokes would be pressed rapidly, but they would still have to be pressed.

So, it sounds like we're totally on the same page.

Comment 13 by briang1 on 2011-11-16 05:36
I've been eavesdropping on this with some interest, and apologies if I've grasped the incorrect end of the stick here, but I've been attempting to figure out the best way to read tables in Word where the entries tend to have large amounts of text in perhaps one cell without having to cursor down for some time now. these matrice tables as I tend to call them seem to be loved by committees atributing actions to members and give me aheadache! Would implimenting this help me to read these ase just a single row?

Comment 14 by aleksey_s (in reply to comment 9) on 2011-11-16 10:57
Replying to jteh:

Now, if you're saying that the current cell would still get read after the requested column or row, I find myself, as a user, asking, but why? It's simply a row based command, why does the current cell have to be read?

NVDA always speaks information changes as they are encountered according to the user's config so that you know where these changes occur. For example, if you are reading a line, it will always read the links in that line. By the above logic, reading a line shouldn't read the links contained in that line. Doing otherwise for different commands introduces inconsistency. If the config says "report table row/column coordinates", they should always be reported. This is both an implementation and a usability issue.

Do you think there is any sense in hearing coordinates of every cell when requesting reading of whole row, or, equally, hearing row numbers when requesting reading of whole column?

Comment 15 by jteh (in reply to comment 14) on 2011-11-16 20:34
Replying to aleksey_s:

Do you think there is any sense in hearing coordinates of every cell when requesting reading of whole row, or, equally, hearing row numbers when requesting reading of whole column?

Sure. That's like asking whether there's any sense in reading any changes when reading by paragraph. If there is a lot of text in the row or column, the user might want to know where the cell boundaries are, especially as a row or column can span several paragraphs. If the user doesn't care about boundaries, they can disable reporting of coordinates/headers.

Comment 16 by briang1 on 2012-03-08 10:07
And that clirifies my question as well then. I like this idea a lot. It would make it a lot easier to form a mental picture of these tables I think.
Also see ticket 2154 as it seems related to this.

Comment 17 by blindbhavya on 2014-08-25 13:05
Hi.
I too feel that this would be an excellent feature at least for all those (including me) who need to take Math notes.
On another non-related ticket I had posted an example expressing why I considered this feature important. However, a few other convincing examples have already been given which all of us have been able to follow, so no point me adding more chunks of text!
Its a long time since this ticket has been commented on, so I wanted to ask, would this be easy to implement? I understand the other more important work devs have to do, but if this can be fixed easily, I would be really excited to use it.
Sorry for being a bit impatient!

Comment 18 by blindbhavya on 2014-08-25 13:07
Changes:
Changed title from "Row/Column Table Navigation" to "feature that allows user to read the whole row/column with a single keystroke"

Comment 20 by blindbhavya on 2014-08-25 16:28
Hi.
Also, if everyone agrees with the implementation of such a feature, then what keystroke could possibly be used?

Well its now 2016 and I'm guessing this feature is not important in the grand scheme of things but it definitely would be one that is useful and I hope at some point will be looked into seriously. As for what keystrokes to use, @blindbhavya, being a JFW user in the main, the first ones that spring to mind for me are alt+win+up and down arrows to read the next/previous row in a table.

#6587 requests this feature specifically for braille.

CC @LeonarddeR

See also #901 (comment) for some excel specific (but relevant discussion)

@mltony would you be interested in implementing this now that #13670 has been merged?

@feerrenrut I think this can be closed as it is now part of NVDA starting with NVDA 2022.3 I believe.

I think a new mode "table skim reading" for table navigation would be really useful. Changing to this mode, the ctrl+alt + arrow keys would automatically read the whole row or the whole column in stead of the current cell.

Actually, there are now key strokes for this feature, but in my opinion they are not very intuitive and that's why I would vote for a skim reading mode, where ctrl+alt+arrow keys can be used for this.

Closed by #14070

@seanbudd, sorry, this issue is not fixed by #14070. Indeed #14070 introduced the following commands:
-read the whole current column

• read the whole current line
• read the current column from current cell downwards
• read the current line from current cell rightwards

The current issue instead is requesting the following commands:

• move one cell down and read the line of the destination cell
• move one cell up and read the line of the destination cell
• move one cell left and read the column of the destination cell
• move one cell right and read the column of the destination cell

These are the equivalent of Jaws scripts alt+windows+up/down/lift/rightArrow.