For me, this issue is alleviated somewhat with the latest versions of Canary, however it does still occur. I would say that 50-60 percent of the time, NVDA is placed in the body of the website without repeating "unknown".

Able to reproduce the issue in canary 51.0.2701.0 but not always.
However the speech viewer "unknown" shown repeatedly(3+ times) in between other texts.
In latest stable 49.0.2623.110 was unable to reproduce it,though in the speech viewer the observation is similar.
Wayback to 44.0.2403.39 too produced the repeated unknown(voice) on Win 10.
cced  dmazzoni@ for more input on this to triage further.

I figured this out! This is a regression in M-51, so I'll need to merge this patch once it lands.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fadccf76e38b76a0eb66f750ee668e89754596b7

commit fadccf76e38b76a0eb66f750ee668e89754596b7
Author: dmazzoni <dmazzoni@chromium.org>
Date: Fri Apr 15 19:56:58 2016

Prevent child frames from sending bad accessibility events.

A recent change in M51 to have a separate accessibility tree for
each frame resulted in a subtle regression, where the
BrowserAccessibilityManager for a child frame would send
accessibility events before it was fully connected to its parent
frame. Because of how accessibility events work on Windows, when
an external accessibility client tried to respond to those events
the target node wouldn't be found when calling get_accChild to
retrieve it.

The user-visible manifestation was that NVDA spoke "unknown" a lot,
in response to those bogus events.

The fundamental idea behind the fixes is that a native accessibility
event shouldn't be fired unless the target node is a direct descendant
of the HWND for that tab. This logic needs to handle all of the cases
that arise when we have a separate BrowserAccessibilityManager for
each frame. The specific issues were:

* BrowserAccessibilityManager::GetRootManager was walking up to a parent
  frame without checking that the parent frame linked back to itself.
* MaybeCallNotifyWinEvent was checking its own delegate's HWND rather
  than the target node's delegate's HWND.
* RenderFrameHostImpl::AccessibilityGetAcceleratedWidget should only
  return a valid HWND for the main frame's current frame host.

BUG= 600145 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1892593003

Cr-Commit-Position: refs/heads/master@{#387681}

[modify] https://crrev.com/fadccf76e38b76a0eb66f750ee668e89754596b7/content/browser/accessibility/browser_accessibility_manager.cc
[modify] https://crrev.com/fadccf76e38b76a0eb66f750ee668e89754596b7/content/browser/accessibility/browser_accessibility_manager_win.cc
[modify] https://crrev.com/fadccf76e38b76a0eb66f750ee668e89754596b7/content/browser/frame_host/render_frame_host_impl.cc

Your change meets the bar and is auto-approved for M51 (branch: 2704)

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/90106718b712cb8c4462c2f39bae0e53a05a263b

commit 90106718b712cb8c4462c2f39bae0e53a05a263b
Author: Dominic Mazzoni <dmazzoni@chromium.org>
Date: Mon Apr 18 18:19:08 2016

Merge to M51: Prevent child frames from sending bad accessibility events.

A recent change in M51 to have a separate accessibility tree for
each frame resulted in a subtle regression, where the
BrowserAccessibilityManager for a child frame would send
accessibility events before it was fully connected to its parent
frame. Because of how accessibility events work on Windows, when
an external accessibility client tried to respond to those events
the target node wouldn't be found when calling get_accChild to
retrieve it.

The user-visible manifestation was that NVDA spoke "unknown" a lot,
in response to those bogus events.

The fundamental idea behind the fixes is that a native accessibility
event shouldn't be fired unless the target node is a direct descendant
of the HWND for that tab. This logic needs to handle all of the cases
that arise when we have a separate BrowserAccessibilityManager for
each frame. The specific issues were:

* BrowserAccessibilityManager::GetRootManager was walking up to a parent
  frame without checking that the parent frame linked back to itself.
* MaybeCallNotifyWinEvent was checking its own delegate's HWND rather
  than the target node's delegate's HWND.
* RenderFrameHostImpl::AccessibilityGetAcceleratedWidget should only
  return a valid HWND for the main frame's current frame host.

BUG= 600145 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_site_isolation

Review URL: https://codereview.chromium.org/1892593003

Cr-Commit-Position: refs/heads/master@{#387681}
(cherry picked from commit fadccf76e38b76a0eb66f750ee668e89754596b7)

Review URL: https://codereview.chromium.org/1893213004 .

Cr-Commit-Position: refs/branch-heads/2704@{#95}
Cr-Branched-From: 6e53600def8f60d8c632fadc70d7c1939ccea347-refs/heads/master@{#386251}

[modify] https://crrev.com/90106718b712cb8c4462c2f39bae0e53a05a263b/content/browser/accessibility/browser_accessibility_manager.cc
[modify] https://crrev.com/90106718b712cb8c4462c2f39bae0e53a05a263b/content/browser/accessibility/browser_accessibility_manager_win.cc
[modify] https://crrev.com/90106718b712cb8c4462c2f39bae0e53a05a263b/content/browser/frame_host/render_frame_host_impl.cc