Comment 1 by jteh on 2010-10-03 23:13
Changes:
Milestone changed from None to None

Comment 2 by jhomme on 2010-10-04 11:09
And one to jump to the first cell in the current row, and another to jump to the last cell in the current row please. Thanks.

Comment 3 by EltonLopes (in reply to comment 2) on 2010-10-04 13:10
Possibly, the following keys:
Control+alt+shift+Home: jump to the first cell in the current row
Control+alt+shift+end: jump to the last cell in the current row
or then, I suggest the keys:
alt+shift+Home: jump to the first cell in the current row
alt+shift+end: jump to the last cell in the current row

Replying to jhomme:

And one to jump to the first cell in the current row, and another to jump to the last cell in the current row please. Thanks.

Comment 4 by orcauser on 2010-10-06 08:33
To add to the wish list:
a shortcut key to present (braille flash message/speech) the current cell coordinates.
Thank you.

Awesome stuff!
I would change a few things though.

Control + Alt + Home: Go to the first table cell

This can be done with Shift+comma.

Control + Alt + End: Go to the last cell of the table

This can be done with comma, then upArrow.

And one to jump to the first cell in the current row, and another to jump to the last cell in the current row please.

If we free up Ctrl+Alt+{home,end} as suggested above, then those keys would become available to go to the first/last cell of the current row. If not, then I'd propose a command without the Shift, beause that looks like you are going to select cells.
I wonder if we want something like this for the first/last cell in the column?

a shortcut key to present (braille flash message/speech) the current cell coordinates.

This is already spoken and brailled for every cell.

Control + Alt + Home: Go to the first table cell

This can be done with Shift+comma.

Only in browse mode though

Control + Alt + End: Go to the last cell of the table

This can be done with comma, then upArrow.

Only in browse mode

I propose:

• ctrl+shift+alt+left arrow: go to the first cell in the current row
• ctrl+shift+alt+right arrow: go to the last cell in the current row
• ctrl+shift+alt+up arrow: go to the first cell in the current column
• ctrl+shift+alt+down arrow: go to the last cell in the current column

ctrl+alt+home/end would be the most obvious hot keys for me to jump to begin/end of tables

Barring my comment about the Shift key this makes a lot of sense. And the use of the Shift key is only a minor concern. I like it!

Looks good. I don't think this is on our current road map, but we are happy to accept a pull request for this.

Just realised, its not clear which application this is talking about. Would the expectation be a general solution that works in all tables (Office applications, browsers, etc?)

Definitely browse mode. But for consistency we should probably do Office too. I'm not sure if that is technically easy to do though.

I think it is meant to work in every situation where currently control+alt+arrows work, e.g. in browse mode, but also in multi column list views.

@bhavyashah: Not sure what to think about those 4 key combination problems. What I like about your combinations is that they leave out the shift key as also preferred by @dkager in #957 (comment)

How about ctrl+alt+backspace for start of table and ctrl+alt+enter for end of table?

@leonardder commented on 13 Jun 2017, 00:31 GMT+10:

How about ctrl+alt+backspace for start of table and ctrl+alt+enter for end of table?

This is eating a lot of key combinations already and key combinations are somewhat limited. I'd be inclined to say we should just leave out the start and end of table commands. It's really not that hard to hit jump to top of column then jump to start of row, etc. Alternatively, they could be implemented but unbound by default.

It's worth noting that outside of browse mode, you're going to have to implement these commands separately for every implementation. For Word, we'll probably eventually roll the table navigation commands into browse mode, since we have browse mode in Word now. That still leaves list views, though.

I'd be interested in an example of such a list view.

@feerrenrut could you update the issue title to be more specific?
I think we agreed on:

• Commands to navigate to the first/last column/row.
• Unbound commands to go to the start/end of a table. This basically combines going to the first/last row and column.

Technical

For first/last row/column in browse mode I suggest extending _getNearestTableCell to also accept "first" and "last" as movement directions. The function should probably be renamed to _getTableCell or _getTableCellInDirection.

This requires that back-ends can easily find the last row/column. The first row/column isn't a problem, assuming it always has index 0.

Summary

• We all agree that – (i) navigating to the first/last cell of the current row/column/table are useful for a screen reader user, (ii) overutilization of key combinations should be avoided, (iii) 3-key commands are more preferable then 4-key commands.
• There is some debate on whether navigation to the first and last cell of the table merits separate key commands. Some argue that these would be useful, while others argue that moving to the first cell of the current row and then current column and similarly for the last cell of the current row and column in effect achieve this very end goal of moving to the first and last cell of the table. Keeping in mind the fact that increasingly limited key combinations are available, the best reconciliation of accommodating both sides is by introducing the ability to navigate to the first and last cell of the table as assignments that are unbound by default.
• No consensus as such was finally reached on the most intuitive set of keystrokes, but below is what appeared unrefuted and largely agreed upon:
  Moves to the first cell of the current row – Ctrl+Alt+Home
  Moves to the last cell of the current row – Ctrl+Alt+End
  Moves to the first cell of the current column – Ctrl+Alt+PgUp
  Moves to the last cell of the current column – Ctrl+Alt+PgDn
  Moves to the first cell of the table – unassigned
  Moves to the last cell of the table – unassigned
• The expected scope of implementation of these table navigation shortcuts would be global – all applications, both browse mode and focus mode, list views, etc. However, any technical limitations to this expectation of an ideal implementation will need to be taken into consideration.

A question related to this issue has been asked in an NVDA's spanish mailing list. We will be grateful if you can check this again or if you could accept a pull request. My suggestion is to add the following commands:

• control+alt+home: move to the first cell of the current row.
• control+alt+end: move to the last cell of the current row.
• control+alt+repag: move to the first cell of the current column
• control+alt+avpag: move to the last cell of the current column.
• control+alt+numbers: move to columns from 1 to 10 respect to the current one, considering that 1 is the current column.
  We should consider that control+alt can be used to shortcuts, so, as an alternative, NVDA+control+numbers could be more comfortable.
  @ABuffEr and @mltony worked on reviewing columns and navigation in tables, so I mention them here in case they are interested. I can add commands in source/NVDAObjects/behaviors.py, class RowWithFakeNavigation, if you find helpful a PR from me.
  For reference, this has been asked at
  https://nvdaes.groups.io/g/lista/message/987

I would love this feature, especially at work it would help alot. ctrl+alt however is the better option in my opinion because it is very related to ctrl+alt+arrow keys and it is also easy to keep in mind for beginners.

I implemented this feature in Tony's enhancements add-on:
https://github.com/mltony/nvda-tonys-enhancements
It can be easily integrated into NVDA if someone wants to work on that PR.

This issue is very old. What is blocking?

I would also love have this feature integrated in core. Would be a great gain of productivity when exploring big tables on webpages. Of course, meanwhile @mltony's add-on does the job. Thanks Tony!

Note that this feature is in Jaws for at least 10 years. And on the contrary to other recent Jaws features (OCR, ResearchIt), it is a real screen-reader feature.

If there is too much discussion on this issue, I would suggest making a minimal PR with the parts of this feature on which all agree, i.e.:

• implement only the 4 commands go to start of column, end of column, start of row and end of row
• do not assign default shortcuts

Then additional PRs could be merged if and when an agreement is found:

• assign default shortcut
• scripts to go to first/last cell of the table
• scripts to move to column 1, 2, 3, etc.

The goal to proceed this way would be to avoid waiting another 10 yers.
Thanks.

I agree with Cyrille in moving forward with this. I proposed a way to implement this. If you agree, I can make a PR or at least a draft.

Just to clarify that my proposed implementation is quite incomplete. I have performed a git grep -n to search files containing alt+control+arrow gestures and this require changes in documentbase and files related to Microsoft Word. Also, the number of rows and columns of tables seems not to be explicitly retrieved in documentBase.py. I have looked at TonysEnhancements add-on, very quicly, and I find a value of 500, not the exact number of rows (I maybe wrong, since I have seen this very fast). So, this will require some more staff respect my first thinking.

@feerrenrut Could you please update this ticket with your comments when you are able? This ticket is over a decade old now and while there have been differences on what keystrokes to assign, there seems to have been agreement over the years on implementing unbound gestures for moving to the first/last cell of a row/column. In particular, it might be helpful if you could outline what implementation of this feature, if any, you are willing to accept a pull request for. May I also tag all the code contributors who at some point expressed interest in this functionality: @dkager @LeonarddeR @derekriemer @josephsl @nvdaes @mltony

@bhavyashah The path forward suggested by @CyrilleB79 (#957 (comment)) seems appropriate. As for implementation, this isn't something NV Access is currently looking at. If someone starts to work on this, I'd recommend starting with a prototype (draft PR) and get help with manual testing to look for issues.

Do we have to wait another 10 years?
Would love to see nvda improve on this.