Excel: Navigate to last or first cell containing data in a row/column while in browse mode

[nvaccessAuto]

Reported by siddhartha_iitd on 2015-10-08 04:37 In MS Excel if Cells are Protected and Selection Disabled, there should be a way to read any given row/column, to know the last data containing cell in a row/column, especially if the data is sparsely filled. Moreover, there should be a way to directly navigate to first/last data containing cell of any row/column.

This is already implemented as a solution to #4952. It's available in branch in_t4952_nvdaobj at https://bitbucket.org/manish_agrawal/nvda

[nvaccessAuto]

Comment 2 by jteh on 2015-10-08 06:10 I don't follow the justification here. If you are in browse mode, you can select protected cells, so once browse mode is enabled, usage is pretty much the same as for a normal sheet. Please provide an example of how this would be used and why navigation in browse mode is not sufficient.

[nvaccessAuto]

Comment 3 by siddhartha_iitd on 2015-10-08 07:05 Excel commands to move to last/first data containing cell in a row/column are Ctrl+End and Ctrl+Home. These commands don't work in browse mode. Further, in normal mode if cells are protected these commands don't work. This would improve the efficiency of navigation, especially if the data is entered in a discontinuous or sparse manner.

[nvaccessAuto]

Comment 4 by sumandogra on 2015-10-08 09:51 Use Case: in an organization that deals with financial matters, a screen reader user may have to cross check many sheets according to his work profile. in scuh senarios going to first and last cells in a row and column and commands to read the compelte row and column in one go are helpful to finish the tasks sooner. using ARROWS to go to eacj and every cell to erify the info provided in the sheet by someone will other wise take a lot of time.

[nvaccessAuto]

Comment 6 by jteh on 2015-10-08 21:50 Okay. So this isn't really specific to protected sheets at all... or is it?

The commands to read the row/column read the row/column coordinates as they go. Given this, isn't it almost as slow as reading with the arrow keys?

[nvaccessAuto]

Comment 7 by sumandogra on 2015-10-09 06:48 Usually in an organization one has to work on many sheets and not just one or two. On using ARROWS to move down, up, left and right will surely consume time and will be a cumbersome task. As one will not know if there are blank cells within a row or a column. One will unnecessarily spend those few moments navigating to such blank cells with arrows. As data may be spread over in a random manner so using just arrows may lead to wastage of time in each sheet leading to a large wastage of time in total when dealing with many number of sheets at a time. With such quick commands time will be saved and one need not use arrows again and again. Please note, a sighted person will immediately know the cells with data in between the blank cells but a screen reader user has to search for the cells with data in sheets that have data written in random manner.

[nvaccessAuto]

Comment 8 by siddhartha_iitd (in reply to comment 6) on 2015-10-12 04:41 Replying to jteh:

Okay. So this isn't really specific to protected sheets at all... or is it?

This is for the case when cells are protected and selection disabled irrespective of if the sheet is protected or not. I think protected sheets refer to password protected sheets, in which case a user might not even be able to read the contents of sheet without the password.

The commands to read the row/column read the row/column coordinates as they go. Given this, isn't it almost as slow as reading with the arrow keys?

No. If not all cells in a row/column contain data, these commands will a) inform the user about location of data containing cells b) prevent the case of missing the data just because the user doesn't know the range of cells where data exists. Even if the data is represented in cells in continuation, it will still be faster as it saves the time of navigating to each and every cell. Moreover, these commands just read the content not the formatting information. So, I believe that will further improve the efficiency.

[nvaccessAuto]

Comment 9 by sumandogra (in reply to comment 8) on 2015-10-12 07:10 as replied by siddarth, the sheets referred to here are not password protected sheets but the sheets that have cells protected in them. when cells are marked as protected in a sheet, those particular cells become non editable and the persons who are given to fill such sheets are not able to edit all the cells but can only fill in the data in the cells made editable by the designer of the sheet. all in all the cells are restricted by the person who has created the sheet in an official environment.

[jcsteh]

@DineshKaushal: As discussed on the call today, it'd be great if we can get an updated summary of what is needed here. The inability to move to locked cells no longer applies, since browse mode now allows this. Note the following:

1. A quick look at the code suggests we might need to add control+home/control+end to handle locked cells in browse mode.
2. We also need a use case and expected behaviour for row/column reading commands; e.g. why it's more efficient than just cursoring through the sheet, whether empty cells should be skipped, whether coordinates should be read, whether regions should be respected, etc.

[ehollig]

This sounds similar to the feature requested in #1911

[feerrenrut]

There is also #901 which covers reading Rows and Columns and is specific to excel.

The difference between this and #1911, if I'm not mistaken, is that it also aims to cover navigating to the the last cell with data in a row or column (in browse mode).

Edit: comments about reading rows/columns moved to https://github.com/nvaccess/nvda/issues/901#issuecomment-347768589

[feerrenrut]

Given there is #901, which discusses reading the row/column in excel, I will move the relevant parts of the previous comment there, and morph this issue to be specific to navigating to the final data filled cell in a row or column while in browse mode.

[Adriani90]

I am working as an analyst in finance and I am dealing with big financial models almost every day. If the sheets are well organized you can easily navigate by data regions and from first to last row or column of a data region by holding down the ctrl key and pressing the arrow keys. With ctrl + end you can go to the last column of the sheet which contains at least a data cell and then press ctrl+ up to go to the begining of the last data region or ctrl + left to go to the last data cell in the last data column. I don't really see the issue here.

However, try doing following:

1. In an empty sheet write Hello in e10
2. Write Hey in e20
3. protect the sheet and be sure that users are not allowed to sellect protected cells.
4. Be sure that users are allowed to sellect unprotected cells

Result: In focus mode you will not be able to navigate through the table at all which is ok. But in browse mode everything works fine.

To reproduce this more clearly, go to e10, right click on it and go to formating cells dialog. Go to "protect" and uncheck the checkbox for protecting that cell. Do the same for e20. Now if you protect the whole sheet again and make sure the users are not allowed to sellect protected cells but only unprotected cells, following will happen:

• NVDA will jump only between e10 and e20 everytime you press an arrow key.

In many sheets, diferent cells are protected individually, so that it will not be possible for NVDA to structure the data in focus mode in such a way that you can navigate to the protected cells. But browse mode works very fine so I think there is no problem about that.

[feerrenrut]

Thanks @Adriani90, I wasn't aware of those shortcuts, could you mention the version of Excel you used to test this please? I can confirm this works well in browse mode for Excel 2013.

I'm not sure what behaviour the following was supposed to trigger:

A quick look at the code suggests we might need to add control+home/control+end to handle locked cells in browse mode

I assumed it was the behaviour we currently get from ctrl+left / ctrl+right while in browse mode.

[Adriani90]

Hi, I used Excel 2010 and excel 2016.

Von meinem iPhone gesendet

Am 04.12.2017 um 02:24 schrieb Reef Turner notifications@github.com:

Thanks @Adriani90, I wasn't aware of those shortcuts, could you mention the version of Excel you used to test this please? I can confirm this works well in browse mode for Excel 2013.

I'm not sure what behaviour the following was supposed to trigger:

A quick look at the code suggests we might need to add control+home/control+end to handle locked cells in browse mode

I assumed it was the behaviour we currently get from ctrl+left / ctrl+right while in browse mode.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[feerrenrut]

I think testing of this in Excel 2010, 2013, and 2016 is good enough coverage to close this issue. So if I'm missing the point (perhaps some other behaviour is expected from ctrl+home / ctrl+end) or someone else gets different results please comment here.