Change Say All behaviour in Excel to read entire worksheet from current point when not in edit mode

[Qchristensen]

In Excel, when not in Edit mode (To go into edit mode, move the focus to any cell and press F2), NVDA does not read anything when the Say all command is pressed (NVDA+down arrow or for laptop layout, NVDA+a).

Having the Say all command read the worksheet from the current point onward would be consistent with behaviour in other apps (including tables in Word or on the web).

I envisage having it read:

• As per the current language (eg, left to right, top to bottom for English).
• Only read cells with displayed content.
• Read cell headers as per the document formatting setting for Say All
• Don't read formulae, only displayed results.

[feerrenrut]

I think this is probably quite a bit of work, I have assigned it a priority 3 for now. @Qchristensen does this sound ok to you?

[Qchristensen]

That's fair enough, thanks!

[Adriani90]

@Qchristensen I am not sure this is possible. actually Excel does not have the concept of lines, paragraphs, characters etc. when not in editing mode. So say all would need to be completely redesigned for Excel to

1. Recognize where content begins and where it ends
2. don't read empty cells
3. Read things in contextual way (e.g. there could be two tables or content regions next to each other but without any context to each other, so the say all in that case would have to apply only for one of the tables or content regions.

I am not sure what exactly the use case is for this feature. I think in such data structurues users will have to apply navigation commands provided by Excel natively. I attach here an excel sheet that is an usual way of working with this application in professional contexts. Honnestly I think say all would not bring any benefit here. After the first couple of lines users will be lost anyway in the contexts. Excel is always a thing of understanding the structure by navigating it first, and then reading the parts that are relevant for you.

BusinessCase_25.01.24.xlsx

[Adriani90]

So do you think this can be closed?

[XLTechie]

@Qchristensen Other than consistency with other apps, what is the practical value of this feature? What is the "user story" here?

[Adriani90]

We don't have any updates on this upon request since many years, and I cannot son't see a valuable use case for this feature. I am closing as not planned. If you have any user story and strong arguments for this feature, please comment and we can reopen.

[XLTechie]

@Qchristensen can you please consider my question above?

As much as I agree with @Adriani90 about the probable lack of value in this feature, it is a staff ticket and unfortunately should have been left open, per triage guidelines.

[CyrilleB79]

I disagree with the lack of value of this feature.

Exploring an Excel sheet in which the user does not know the structure of the content is challenging in my view. E.g. Excel sheets containing two or more tables separated with one or more vertical columns. Or a sheet with rows with inhomogeneous number of cells. Having an easy and systematic way to have no empty cells listed and read in an Excel sheet would be very useful.

The alternative workaround is:

0. Press control+end to see where the last cell of the sheet is.
1. Start at A1
2. Press left arrow
3. Repeat step 2 until you reach an empty cell
4. Press control+left arrow
5. a. If you landed in a cell with content repeat step 2 to 4
6. b. If you landed to last cell of the row (XFD1), press control+leftArrow as much as needed and then downArrow to reach the first cell of the next row (B1)
7. Repeat step 1 to 5 to until you have reached the last row.

Automatically navigating to cells with content would need much less keypresses than this workaround.

[Adriani90]

@CyrilleB79 I think you mix this with #9145 which suits better for your use case. Say all will not help with this at all, especially when Excel sheet are as complex. See the excel file I attached in https://github.com/nvaccess/nvda/issues/6624#issuecomment-2051629064 Vertical columns are not always related to each other, so with a say all reading everything from left to right and from top to bottom is not an improvement at all.

If you want to move quickly to non empty cells, you can use the array formula and extract all the data from a table without empty cells. This is a bit unintuitive but still it is a work around for #9145. https://www.ablebits.com/office-addins-blog/remove-blank-cells-excel/

[CyrilleB79]

Yes I agree that #9145 is probably a better solution to explore an unknown sheet.

Regarding say all in Excel, maybe there is another issue tracking this, but what would make more sense is to say all by row or column as implemented by @mltony in tables. In case it does not exist, it would be better to open a brand new issue for this though.

[Adriani90]

There are already #1911 and also #901 for reading whole row / column. I can imagine it could help tables with defined borders, but not in plain MS Excel data regions. For data regions with undefined borders, even reading the whole row or the whole column is not really helpful in Excel, because data regions which are not directly related can be directly next to each other or on top of each other. So reading the whole row or column in such data regions does not really give any impression about the structure. However, in MS Excel creating tables with ctrl+t is possible, and they have defined borders. But they are not very common in practice and NVDA does not announce where such tables start and where they end.

If you want to understand the structure of an excel worksheet, you have to find the way around it by using the navigation keystrokes provided by MS Excel. There is no other way yet unfortunately, and say all or reading whole row / column will not bring any revolution in this regard. This might change with multiline braille displays or grafic braille displays, or maybe using AI to give a summary of the structure.

[Adriani90]

@seanbudd did you have any talks at NV Access about this issue? As explained above, i don't see any valuable use case for say all in Excel, this is also confirmed by @XLTechie above. The policy says we should not close NV Access created issues, so please feel free to decide whether this should be closed or not.

[Adriani90]

I am closing this for now. Please provide a reason why this should still be open so we can continue discussions on this request.

[CyrilleB79]

As already explained by @XLTechie in https://github.com/nvaccess/nvda/issues/6624#issuecomment-2136821542, this issue should remain open as per triage guidelines.

Personally, I have no objection to close it though, as per https://github.com/nvaccess/nvda/issues/6624#issuecomment-2137295075.

[Adriani90]

The policy as it is now in this regard doesn‘t make sense, in this case someone not related to NV Access could work on such issues despite clear and valid use case. I want to challenge the policy in this regard, so if NV Access still insists on it they should reopen with a clear use case evidence. I understand the current policy makes sense for p1 or p2 triaged requests, because those are directly atributed to NV Access. But this is a request at p5 at best, and as such it is delegated to the community. Since there is no support for this from the community, I am closing again. Please don‘t reopen until NV Access gives other indications.

[CyrilleB79]

The policy as it is now in this regard doesn‘t make sense, in this case someone not related to NV Access could work on such issues despite clear and valid use case.

@Adriani90, there has been an opportunity to discuss this policy few time ago when #16503 was submitted. Though if you have not been able to discuss it at that time for whatever reason, or if you have realized afterwards that this policy is not suitable, that's not a problem: you can open a new discussion about it and involve NV Access in it.

I want to challenge the policy in this regard, so if NV Access still insists on it they should reopen with a clear use case evidence.

IMO, it's a very bad practice to challenge the policy this way, spamming the issue with unrelated discussion.

Since there is no support for this from the community, I am closing again. Please don‘t reopen until NV Access gives other indications.

I won't reopen since it's not a way to discuss triage policy. I'll let NV Access do so if needed and I'll hide my comment after they have answered.

@seanbudd and @gerald-hartig could you please comment on the policy, here or elsewhere.

@Qchristensen could you reopen with a justification or confirm if you wish this issue to remain closed?

[gerald-hartig]

@Adriani90 Although we appreciate how keen you are to keep NVDA moving forward by going through our older tickets, sometimes it takes a bit of time for NV Access to be able to contribute to the discussion. Also as @XLTechie mentioned since this is a ticket that NV Access opened, we'd prefer if you left those open and @ us with a message that you think this one should be closed.

In this case, it does appear that there is still some discussion worth having and I'd like to get @Qchristensen to comment on this issue and the alternatives before it's closed.

[Qchristensen]

Apologies for my disappearance on this one everyone! So, sticking to the original issue:

This did come up originally from a user request. It's not the most regularly requested feature, but it does come up. I just had a look through my emails and I can find a couple of very simply worded requests for it where I've referred to this issue, but not one with more detail. Say all would certainly be of more use in some contexts than others in Excel. I admit I didn't originally consider the use case of multiple tables on a sheet, and I agree the either #1911 or #901 would meet a good portion of the need for say all. That would perhaps be a good starting point for a solution to this, as then the further need for say all in Excel could be evaluated.

The workaround currently to achieve this: 1) Select a row (shift+spacebar), column (control+spacebar), all (control+a - note you may need to press several times as it only selects contiguous cells with content initially), or any other region. 2) Copy to clipboard (control+c) 3) Have NVDA read the contents of the clipboard (NVDA+c). Note that does not work with large sheets as NVDA will only report the number of characters above a certain limit (512 from memory?)

Looking through some of my own spreadsheets, I can absolutely see some which could be read logically via a say all command, and some which wouldn't make as much sense.

In terms of the validity of the issue, I think it is still valid, albeit the level of demand for it combined with the technical challenges of implementing it mean that the priority is going to be low.

[Adriani90]

@Qchristensen thanks for your input on this issue. I still struggle to find a reason why developers should invest time in this because I don't really see users benefits by using say all in Excel sheets. In fact, people can always save the Excel file as htm document or as pdf document by pressing f12 and choosing the file type, and then the say all can be used in the browser or Acrobat Reader. However, doing this for tables in my view is an overload when trying to understand the table structure. Maybe it makes sense for a small table of say 5 rows and 3 columns or so (very uncommon in Excel), but at a certain point this will not be useful anymore in larger tables. Given the workaround of saving the file as another file type where the say all is supported, do you think this should still remain open?

[CyrilleB79]

The workaround is much less efficient than say all in any case so it should not be the reason why this issue would be closed if it is.

Since this feature has been asked various times to @Qchristensen but no strong use case has been exhibited, I'd vote to keep this issue open but with with a low priority. Low priority means that if a developer choose to work on it, it's probably because they feel a personal need to this feature.

@Qchristensen do not forget to ask more information on the use case and report it here next time someone ask you this feature.

[Qchristensen]

Thanks Cyrille,

The main use cases I can think of (and yes I'll be sure to add others as I get any future requests for this) is not so much the "Table of 100 rows and 20 columns of figures" type spreadsheet, but rather the more textual spreadsheet. We get sent security checklists by companies for instance with two columns, one of questions and the second column to fill in the answer - I can see using say all as a quick way of reading through the answers to a document like that (particularly where you may not need to stop and analyze each response in detail). Also I've seen spreadsheets with lots of text - which probably should be Word documents, but in the case where a user is sent such a document, the burden shouldn't necessarily be placed on the user to reformat it to read when you should be able to tell the screen reader to read it (When I first created the issue I didn't appreciate all the technical issues in doing that).

I think #1911 or #901 would likely resolve a lot of the use cases for this (though not necessarily my first example above unless it had the ability to say all in the column with two columns selected, but I'd be happy to take A solution as a starting point and deal with additional use cases as they arise.

I think it's worth keeping this issue open at least until one of those is implemented to see which use cases are still left at that point.

[CyrilleB79]

I agree that the use case of Excel sheets used as word documents is a valid one.

That's the case for example in my company where the facilities send an Excel sheet when they need to inform of a technical intervention causing power outage in the buildings. Or when the doctors send an appointment. The reason why they use Excel sheet rather than Word / E-mail is probably because they have some sort of automatic processing associated with it.