Repository: nvaccess/nvda

Issue:
Suppress layout tables when reading messages in Outlook with UIA for Word enabled
<!--
Please thoroughly read NVDA's wiki article on how to fill in this template, including how to provide the required files.
Issues may be closed if the required information is not present.
https://github.com/nvaccess/nvda/wiki/Github-issue-template-explanation-and-examples
-->

### Is your feature request related to a problem? Please describe.

When using the "Use UI Automation for Word controls" enhanced setting, reading messages in Outlook exposes way more information, and is more performant, than if this setting is off. However, in newsletters, layout tables are often used to place images or headers, or add other eye candy. With UIA for Word enabled, each and every table, nested and otherwise, is reported. This makes reading newsletters a real pain.

### Describe the solution you'd like

NVDA should apply some heuristics when reading messages in Outlook to suppress tables that are clearly for layout. It already has some heuristics to determine layout tables, and if needed, could also take some inspiration for how Firefox determines if a table is a layout table. Especially those tables that only have one column and/or row are clearly not data tables and could be suppressed safely.

### Describe alternatives you've considered

There aren't really any, since turning off UIA for Word makes the reading experience in Outlook far worse because of performance. Such newsletters suddenly take one to two seconds for each press of the DownArrow to read the next line and refresh the braille display. So the only way is to make UIA in Word the default, and if that's the case, also add some heuristics to suppress layout tables when reading.

### Additional context

This came from a discussion with acquaintances who claimed that NVDA was still not ready for most workplace scenarios due to poor outlook support. I did some comparative testing between JAWS and NVDA, and besides the performance improvements I got when I turned on UIA for Word Controls, found this to be a real blocker for most users.



Discussion:
cc: @michaelDCurran, @leonardder 
I highly encourage the team to prioritize this issue. The productivity hit with HTML reading is becoming significant. At this point, I do not have the time or the inclination to learn a completely new email/calendaring solution such as Thunderbird; nor do I particularly desire to start using JAWS on a daily basis.
Any update for this issue?
With the merger of #12770 this issue can no longer be worked around.
I have suppressed all table announcements in MS Outlook and saved it as an application-specific profile. This has the unfortunate  side effect of not having table announcements available when data tables need to be announced either while reading or composing email in Outlook. 
After a lot of investigation, I am unable to find a way to specifically identify layout tables from data tables.
Outlook could address this itself by not exposing the Table pattern interface in its UI Automation implementation on layout tables. I believe this is what the UI automation implementation in Chromium is doing.
Perhaps for now:
In the Outlook message viewer (I.e. reading not composing) if a table has only 1 row or 1 column, then we can treat this as a layout table and suppress its reporting.
Testing this shows that this removes probably about 75% of unuseful table reporting when reading Outlook messages. 
If we wanted to catch more, we could instead just ignore all tables when reading Outlook messages. This would still allow tables to be reported when composing, but would possibly incorrectly ignore some valid data tables  unreported when reading emails. Though the question is, how common are data tables when reading Outlook messages? Is this still better than having all layout tables read?
I'm happy to implement either option here:
* Ignore tables with 1 column or 1 row when reading Outlook messages, or
* Ignore all tables when reading Outlook messages.

Which one would people be most happy with?

I will continue to also try and get Microsoft to drop the table pattern from layout tables in read-only Outlook messages, though I'm pretty sure I've asked for this several times in the past.
Personally, I would prefer just ignoring tables with 1 column or 1 row. If I need to, I can quickly toggle the rest off.
I’ve seen quite a few emails with data tables. They’re generally more frequent in the business world. Might I suggest a third option? It’s more of a combination of the option to suppress all tables and the ability to open the contents in Microsoft Word. As I’ve said before in this thread, I’ve suppressed all tables via ap specific profile. It works for me except in cases where there are data tables. I usually copy and paste all the contents from that email to  a new Word document. If you can suppress all tables and allow us to assign a key combination to a function which automatically copies and pastes the contents of an email to a word document, it would solve the problem. Most people won’t need the latter functionality. But, those of us who do will have a convenient and effective method of reading data tables if needed. Given Microsoft’s intransigence on this matter, it seems like the most efficient way to resolve this. There used to be a way to open an email in a browser window. I haven’t been able to find that functionality.

I was just thinking that, given that Microsoft is moving all this office stuff to web technologies, AFAIK starting with Outlook, they might move the underpinning to Electron/Chromium, too, or just run it all in the browser as a PWA in future anyway. In that case, this bug would become obsolete because then, everything opened in a web browser anyway which has proper layout table heuristics. And the more robust API for this, AKA browser knowledge plus IA2. At least for the time being, that doesn't seem to go away.
Unfortunately, the timeline for the Outlook remake isn’t clear yet. I understand that it’s being planned. As far as I understand, Microsoft isn’t planning to get rid of the standard, non-Office 365 version of Outlook either, making a fix necessary.


Resolving patch:
diff --git a/source/NVDAObjects/UIA/wordDocument.py b/source/NVDAObjects/UIA/wordDocument.py
--- a/source/NVDAObjects/UIA/wordDocument.py
+++ b/source/NVDAObjects/UIA/wordDocument.py
@@ -199,6 +199,19 @@ def _getControlFieldForUIAObject(self, obj, isEmbedded=False, startOfNode=False,
 				or field.pop('name', None)
 				or obj.name
 			)
+		# #11430: Read-only tables, such as in the Outlook message viewer
+		# should be treated as layout tables,
+		# if they have either 1 column or 1 row.
+		if (
+			obj.appModule.appName == 'outlook'
+			and obj.role == controlTypes.Role.TABLE
+			and controlTypes.State.READONLY in obj.states
+			and (
+				obj.rowCount <= 1
+				or obj.columnCount <= 1
+			)
+		):
+			field['table-layout'] = True
 		return field
 
 	def _getTextFromUIARange(self, textRange):


Test patch: