Excel column/row headers are not displayed in braille

[dkager]

At least in Excel 2016 and 2013.

STR:

• Open an empty sheet.
• Type 'Foo' in A1 and 'Bar' in B1.
• Select A1 through B2.
• Press Ctrl+L to create a new table and check the box to indicate the table contains headers.
• Go to B1. The header text is not displayed.
• Go to A1 and press NVDA+Shift+C to mark the start of the headers.
• Go back to B1. The header is still not displayed.

[dkager]

CC @jcsteh

[jcsteh]

• Go to A1 and press NVDA+Shift+C to mark the start of the headers.
• Go back to B1. The header is still not displayed.

NVDA+shift+c sets the column header; i.e. doing this in A1 sets the headers for A2, A3, etc. So, I wouldn't expect B1 to show the header in this case. However, it's also not shown for A2, so the bug is still valid.

Corrected STR:

1. Open a new sheet in Excel.
2. Type 'Foo' in A1 and 'Bar' in A2.
3. Move to A1 and press NVDA+shift+c to set it as a column header.
4. Move to B2.
5. Move back to B1.
   • Expected: 'foo' should be shown in braille as the column header, along with the value 'bar'.
   • Actual: Only the value 'bar' is shown.

[jcsteh]

This is addressed by/a duplicate of #4195. In speech, we only report the headers when you first move into that row/column. We don't conditionally report things like that for braille. However, that means you'll keep seeing the row and column headers repeated every time you move to a new cell. I'd appreciate thoughts on UX here from you constant braille users. :)

[dkager]

Hah, I actually meant A2, but the matrix got me. :)

[dkager]

However, that means you'll keep seeing the row and column headers repeated every time you move to a new cell.

This returns us to #217. IMO it's better to see the column/row headers for every cell (as is done in Word and in browse mode) instead of not seeing them at all. My use case is something like a budget sheet with 20+ columns. You don't need all of them at the same time, but remembering that many is still a memory burdon. But as with general focus mode, a more sophisticated solution would be nice. Still, in the way I use Excel (which is obviously subjective) I would prefer all over none.

[LeonarddeR]

I think that we should handlerow and column headers similar to focus ancestry indeed. Changes proposed in #217 could be applied here as well.

[jcsteh]

#217 doesn't apply here, since row/column headers are not separate objects (and thus not separate regions) when rendered for a cell. Also, #217 only changes where the display is scrolled, whereas for row/column headers, I think we'd have to exclude the information altogether (unless you're suggesting the headers should be presented before all other info in the cell, including the coordinates, in which case maybe we could do something interesting with scrolling).

[dkager]

So in Excel you see this if you type 'bar' in A2:

Book1 - Excel Sheet1 tb bar A2

I agree it's not as easy to find a good spot to insert row/column headers as it is in Word, mostly because the A2 contains both row and column indices. I also understand the technical limitations, thhough as an end-user that won't stop me from requesting stuff like this. :)

So my (subjective) stance on this is that the column/row headers are useful even in braille. But in the current output there is no logical place to put that info. We could consider:

Book1 - Excel Sheet1 c1 Foo r2 bar A2

This is super verbose and redundant, and may again result in technical difficulties. But I can't do better right now.

[feerrenrut]

Presumably the braille output of this could be tied to the "report table headers" setting in the document formatting dialog. This would allow those that don't want this extra verbosity to be able to turn it off.

[LeonarddeR]

@JCSTeh commented:

unless you're suggesting the headers should be presented before all other info in the cell, including the coordinates, in which case maybe we could do something interesting with scrolling.

That seems to be the most logical way to do this.

How about the following implementation:

1. Create a new region class called TableCellRegion which subclasses NVDAObjectRegion
2. For this new subclass, add a property which contains the start position of the actual cell content in L{rawText}. From that property, we also have the position in L{brailleCells}
3. Change BrailleBuffer._set_windowEndPos in a way that always shows the cell content on the display, similar to focus objects

After reading this, you will probably understand why I came up with #217 here. We can do hard left for cells, which requires to always scroll back to see the column and row header.

@DKager commented:

Book1 - Excel Sheet1 c1 Foo r2 bar A2 This is super verbose and redundant, and may again result in technical difficulties. But I can't do better right now.

This is verbose, but it is valid and I think we should go for this one

[LeonarddeR]

1. Create a new region class called TableCellRegion which subclasses NVDAObjectRegion

Coming back to this, this seems to be overkill just for one property. I guess we can extend NVDAObjectRegion for this

[LeonarddeR]

@DKager suggested:

Book1 - Excel Sheet1 c1 Foo r2 bar A2

After thinking about this a little more, the problem I see with this is that there is duplicate info in it, i.e. c1 r2 reflects cell A2.

Also, A2 in this example doesn't have cell contents. I'd like the cell contents after the coordinates, thus, Alternative suggestion:

Book1 - Excel Sheet1 c Foo r bar A2 thisIsACell

[Adriani90]

Wow this will be really tricky to implement in my opinion because of the limited space on a braille display. But definitely useful especially with regular braile users. One suggestion for implementation from my side: Is it possible to add a key stroke in NVDA'sexcel app module to report row or column header on demand? In this case we could emulate that key stroke on a braille display and we would not need to have it displayed on it every time when mooving around.

[dkager]

I think the suggestion for an NVDA command to show row/column headers in braille should also be considered for Word, where pretty much the same problem exists with space on a braille display.

[ruifontes]

One way is placing that information before the cell content... That way, using the "Focus context presentation" set to "Only when scrolling back" it is easily accessible and it will not occupe space in the Braille display...

[Adriani90]

I think this is not a very good solution due to following reasons:

1. Users expect actually to see the content of the previous cell when pressing the left scroll key
2. More and more users request a feature where NVDA displays more than one cell on a braille line (especially for cells containing numbers).
3. What happens if you scroll to the left and see the column header and then press a routing key on a character? Will the cursor jump to the column header? This would definitely not be a desired behavior
4. In which order would the headers be displayed? Row header then column header? Or vice versa? I can imagine that users could get confused after navigating for a longer while trough a complex table.
5. Imagine you have years set as row header and date (mm-dd) set as column header. The table contains let's say sun hours. Then you would have shown on the braille display following while scroling:

07-22 2019 12 2020 12 2021 12 2022 12 2023 12 07-23 2019 11 2020 11 2021 11 2022 11 2023 11

This tables says basically how many hours aday the sun is shining in year x on date y. But I am 100% sure that no user would like to read a table in this way.

In my view, I would like to see on a braille display just the content without headers and when I press a routing key on a cell for example the row and column header should show up for some seconds.

[ruifontes]

Adriani, when you scroll back you use the panLeft key...

Rui Fontes

Às 21:44 de 01/04/2019, Adriani90 escreveu:

I think this is not a very good solution due to following reasons:

1. Users expect actually to see the content of the previous cell when pressing the left scroll key
2. More and more users request a feature where NVDA displays more than one cell on a braille line (especially for cells containing numbers).
3. What happens if you scroll to the left and see the column header and then press a routing key on a character? Will the cursor jump to the column header? This would definitely not be a desired behavior
4. In which order would the headers be displayed? Row header then column header? Or vice versa? I can imagine that users could get confused after navigating for a longer while trough a complex table.
5. Imagine you have years set as row header and date (mm-dd) set as column header. The table contains let's say sun hours. Then you would have shown on the braille display following while scroling:

07-22 2019 12 2020 12 2021 12 2022 12 2023 12 07-23 2019 11 2020 11 2021 11 2022 11 2023 11

This tables says basically how many hours aday the sun is shining in year x on date y. But I am 100% sure that no user would like to read a table in this way.

In my view, I would like to see on a braille display just the content without headers and when I press a routing key on a cell for example the row and column header should show up for some seconds.

Von: ruifontes [email protected] Gesendet: Montag, 1. April 2019 22:23 An: nvaccess/nvda [email protected] Cc: Adriani90 [email protected]; Comment [email protected] Betreff: Re: [nvaccess/nvda] Excel column/row headers are not displayed in braille (#6901)

One way is placing that information before the cell content... That way, using the "Focus context presentation" set to "Only when scrolling back" it is easily accessible and it will not occupe space in the Braille display...

You are receiving this because you commented. Reply to this email directly, https://github.com/nvaccess/nvda/issues/6901#issuecomment-478732693 view it on GitHub, or <https://github.com/notifications/unsubscribe-auth/Aaon8SnZd7XwgEkc6QOF3U09q B-Wqx2Hks5vcmqRgaJpZM4MGYL-> mute the thread. <https://github.com/notifications/beacon/Aaon8XtsAqGhWwT7PMt3Up9keYouEadlks5 vcmqRgaJpZM4MGYL-.gif>

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/6901#issuecomment-478740479, or mute the thread https://github.com/notifications/unsubscribe-auth/APIHxovmnojiMnBE4wmEKV-VsZNSukGjks5vcm-5gaJpZM4MGYL-.

[MarioBatusic]

I'm a constant braille-only user (means,I switch the speech output seldom, only for testing). So, especially in tables with many columns I would very much appriciate having all headers in Braille. And that is no problem to have them for every cell - like it is in Microsoft Office Word.

[michaelDCurran]

Can someone please summarize the most up to date proposed solution here?

[Adriani90]

@michaelDCurran I think the solution proposed in this add-on is the most up to date: https://github.com/AAClause/BrailleExtender/commit/d8241932326dc4a7e70fe6c41323248895d7e423

Note: the add-on is maintained at a very low pace currently.

[seanbudd]

@Adriani90 - what we need is a summary of the proposed solution with a bit more detail, e.g. similar to our feature request proposal or what's proposed in #18980. Some of the limitations with just referencing an add-on for summaries is described in #18980