MS Word focus mode: press downArrow to read content, screen reader skips table

[surfer0627]

If this is the case and have nothing to do for screen reader, user may have a chance to read content and skip table in a Word document. note: This document is in Chinese. Steps to reproduce: case1:

• Open the attachment.
• Press downArrow, (screen reader skips table).

case2:

• Press ctrl+home to move to top line.
• Press end
• Press downArrow, (screen reader reads table content).

case3:

• Press ctrl+home to move to top line.
• Press NVDA+space to switch to browse mode.
• Press NVDA+downArrow, (screen reader reads table content).

testCase_skip_table_content.docx

[feerrenrut]

@surfer0627, thanks for filing this issue and providing test cases. I have tried the attached test case document. The described behaviour seems to happen visually (in MS Word 2013) without NVDA as well. This seems to be because the table properties text wrap is set to around which means it is valid for characters to appear to the left of the table. By setting the text wrap to None, pressing the down arrow results in the table receiving focus.

Given its valid for text to appear to the left of the table, I'll close this issue.

[surfer0627]

@feerrenrut, thanks for the reply. Actually, I do not know more about table properties settings. Here are some questions:

This seems to be because the table properties text wrap is set to around which means it is valid for characters to appear to the left of the table.

Does this mean that characters appear to the left of the table, and graphics appear to the right? In what kind of case, user will set properties text wrap to around?

By setting the text wrap to None, pressing the down arrow results in the table receiving focus.

Yeah, but this is based on that user who knows there is a table in the document. If screen reader have no way to indicate table properties, maybe, user do not have chance to do this.

[feerrenrut]

Does this mean that characters appear to the left of the table, and graphics appear to the right?

Graphics or text could appear on either side of the table. This allows a small table to be embedded within a block of text, perhaps to help explain it. This is similar to the way that images and other objects can have text "flow" around them.

In what kind of case, user will set properties text wrap to around?

Some cases that come to mind are an article, pamphlet or more "fun" types of work. Often having text edge to edge broken up only by full width tables and images has a very scientific or business report feel to it.

Yeah, but this is based on that user who knows there is a table in the document. If screen reader have no way to indicate table properties, maybe, user do not have chance to do this.

You are right, it would be easy to miss a table in this situation. A solution to this is not immediately obvious, how would you have the presence of the table reported? In the case where there really is text to the left of the table, it would be an interruption to have the presence of a table reported. Perhaps the ideal solution would be to report that there is a choice for the information ahead before the text on the left of the table is being read?

[surfer0627]

Perhaps the ideal solution would be to report that there is a choice for the information ahead before the text on the left of the table is being read?

Agree. Report message E.G. "Table with text wrap around".

[feerrenrut]

I'll re-open this issue, its seems possible that there is something better we can do here. @michaelDCurran what are your thoughts on this? I think there is quite a risk that we will not be able to get this information out of MS Word.

In summary, when a table or object has word wrap enabled, it's easy to "cursor down" through the wrapped text and miss the table or object. To mitigate this, the proposal is to detect that there is some wrapped text ahead, and report that there is an object with wrapped text.

[michaelDCurran]

Note that there are multiple ways to get around this issue:

1. Switch to draft View. Then the arrow keys will never skip the table.
2. Switch to NVDA's Browse Mode. Again, the arrows will not skip the table.

It may be nice to announce something, but I would not place a high priority on this. To be honest, it is better in most cases that a blind person works in draft view when editing, or browse mode when reading. Editing / reading in Print Layout has multiple issues, including not being able to wrap in multi-column sections etc.

We could detect the next inline shape directly after the current paragraph, but I feel the UX won't be that understandable for most people.

[surfer0627]

1. Switch to draft View. Then the arrow keys will never skip the table.

Good point. Before reading your comment, I do not know more about Draft view. User could switch to this by pressing alt+w, e. I also learn more from "Microsoft Word with NVDA EBook".

• Section 2.12 Document Layouts
• Section 8.12 Reading Text in Columns.

note: Remember, when saving a document, the current view will also be saved with it.

[surfer0627]

@Qchristensen, would you suggest that user set "Draft view" as default? I follow the steps from this article, and it seems unable to set. I reopen the document, and Draft view is still not pressed.

[Qchristensen]

You can set Draft view as the default for new documents. You would need to press alt+w, e each time you open a document to ensure it is in draft view. It is possible to do it using macros, although that is an advanced task.

As noted, the table in this document appears as an object because of its alignment. Using the Go To function (control+g) to search for either an object or a table will also locate the table. The accessibility checker also flags the spaces and table alignment as issues.

None of these solutions are easy or obvious to someone not familiar with the document. If reading with NVDA+down arrow / NVDA+a, the table will be read at least. As and when we find a solution for easy navigation to text boxes, it may also be useful here.

[feerrenrut]

Considering there are a few ways that the table / object can be discovered, I'll leave this open and will set a lower priority on this. If someone has an interest in experimenting on UX this would be a good issue to look at.

[Adriani90]

@surfer0627 are you still having this issue with NVDA 2019.1 RC1?

[surfer0627]

@Adriani90 I could still reproduce this issue in 2019.1 RC1.