Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suppress layout tables when reading messages in Outlook with UIA for Word enabled #11430

Closed
MarcoZehe opened this issue Jul 28, 2020 · 10 comments · Fixed by #12820 or #12857
Closed

Suppress layout tables when reading messages in Outlook with UIA for Word enabled #11430

MarcoZehe opened this issue Jul 28, 2020 · 10 comments · Fixed by #12820 or #12857

Comments

@MarcoZehe
Copy link
Contributor

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.

@Adriani90
Copy link
Collaborator

cc: @michaelDCurran, @LeonarddeR

@LeonarddeR LeonarddeR added this to To do in [Project] UIA in Word via automation Aug 6, 2020
@PratikP1
Copy link

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.

@pbsinnett
Copy link

Any update for this issue?

@codeofdusk
Copy link
Contributor

With the merger of #12770 this issue can no longer be worked around.

@PratikP1
Copy link

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.

@michaelDCurran
Copy link
Member

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.

@pbsinnett
Copy link

Personally, I would prefer just ignoring tables with 1 column or 1 row. If I need to, I can quickly toggle the rest off.

@PratikP1
Copy link

PratikP1 commented Sep 6, 2021 via email

@MarcoZehe
Copy link
Contributor Author

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.

@PratikP1
Copy link

PratikP1 commented Sep 6, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
7 participants