Tested on windows 10 using chrome M57 #57.0.2957.0 and issue is reproduced.

Issue is seen from M30 and it is a non-regression issue.

Marking it as untriaged , so that someone would address this.

Thanks!

Here is a small demo to show that Chrome is very close to support Windows Narrator.

1. Open axs.html in Notepad to get an overall structure of the document.
2. Start Windows Narrator.
3. Open axs.html in Chrome.
4. Use mouse to focus on <main> element. Narrator should speak "This is main element, group".

From now on, you can use [Caps]+[Up]/[Caps]+[Down] to move up/down the AXS tree, use [Caps]+[Left]/{Caps]+[Right] to move previous/next sibling node.

Note that the AXS tree might be broader/deeper than the DOM tree, so keep using [Caps]+[Down] and [Caps]+[Left] until Narrator complains no next item.

See attached screen cast, voice used is "Microsoft Mark Mobile (US English)", unfortunately my screen cast software cannot record the blue highlight box by Windows Narrator.

Aim:

To show that Chrome is very close to support Windows Narrator.

Windows Narrator already can navigate through native browser UI like address bar, bookmark star icon, switch tab, Chrome menu etc, but there is no way to navigate to the root of DOM/AXS tree from address bar with [Caps]+[Up/Down/Left/Right] alone.

In this demo, I use tabindex="0" in <main> element so that Chrome can focus on it, this is why Windows Narrator can explore <main>'s children nodes in this demo.

When user focus on Chrome's content area, Chrome should hook to the root of the AXS tree, this will allow very basic support of Windows Narrator. More enhancements can come later.

I hope this demo can motivate AXS team to support Windows Narrator in Chrome. Being able to use Windows Narrator everywhere instead of having to switch back and forth from ChromeVox can provide better user experience.

Please also try this demo in Microsoft Edge with tabindex="0" removed for comparison.

Deleted: axs.html 6.4 KB

axs.html 6.4 KB View Download

Deleted: Windows Narrator test on Chrome - Google Chrome 13_8_2017 8_42_41 AM.mp4 2.5 MB

	Windows Narrator test on Chrome - Google Chrome 13_8_2017 8_42_41 AM.mp4 2.5 MB View Download

Chrome 63.0.3208.0 (Official Build) canary (64-bit) (cohort: 64-Bit)
Windows 10 Enterprise Version 10.0.14393 Build 14393
Firefox 55.0.3 (64-bit)
Microsoft Edge 38.14393.1066.0

Hello,

I was just using Narrator with Chrome, Edge, and Firefox to compare behaviors. I would load the example page provided by loorongjie@gmail.com, tab to the main page element, press Caps Lock + H to start reading from the beginning of the page, and observe. (Note to loorongjie@gmail.com: I enjoyed the They Might Be Giants reference in your example file!)

Chrome: "not on explorable text", unable to read the contents of the page. Able to tab from link to link, reads the link text, and says "link" at the end. Pressing enter on the link does invoke it. 

Firefox: same as Chrome, "not on explorable text", unable to read the contents of the page. Able to tab from link to link, reads the link text, and says "link" at the end. Pressing enter on the link does invoke it. 

Edge: Narrator reads the page as expected, announcing headings, reading text, etc.

This appears to still be broken in all recent versions of Google Chrome up to and including the current Canary (65.0.3285.0). Narrator works in my Content API-based application when I set the accessibility mode to ui::kAXModeComplete. Chrome is currently only setting (ui::AXMode::kNativeAPIs | ui::AXMode::kWebContents) in [1] with the following comment added by dmazzoni@ in https://crrev.com/368ea13e :

    // When an MSAA client has responded to our fake event on this id,
    // enable basic accessibility support. (Full screen reader support is
    // detected later when specific more advanced APIs are accessed.)

I would guess that Narrator is not hitting the "more advanced APIs" trigger.

[1] https://cs.chromium.org/chromium/src/content/browser/renderer_host/legacy_render_widget_host_win.cc?type=cs&q=AddAccessibilityModeFlags&sq=package:chromium&l=177

Currently Chrome supports MSAA, IAccessible2, and ISimpleDOM accessibility interfaces. We have almost no native UI Automation support, just the little bit that comes for free with MSAA support.

The main issue here is for Chrome to implement UI Automation. That's currently a lower priority for us because usage of other screen readers (JAWS, NVDA, ZoomText) is much higher.

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot