Looks like select_to_speak_event_handler is not even getting those search key events, so there's no hope for Select-to-Speak.

I'm guessing the notification views are calling event->StopPropagation before the KeyEvent reaches Select-to-Speak. Is there a way to move Select-to-Speak further up in the order of key event processors?

Dominic, do you know what the notification windows are called? 

Looks like tray_bubble_view.cc stops the event propagation in TrayBubbleView::RerouteEventHandler::OnKeyEvent:

https://cs.chromium.org/chromium/src/ui/views/bubble/tray_bubble_view.cc?type=cs&l=180

Commenting out this one line allows select-to-speak to work on the menu.

+yawano, you added this line in https://chromium-review.googlesource.com/603547. Do you think it's possible to keep propagating key events so that select-to-speak will work on this menu?

Alternatively, I wonder if there is a way to route events just to select-to-speak and no one else? Or let select-to-speak get first dibs at key events before other tools?

Can we register the key combination as an accelerator? The key event is passed to AcceleratorController. For example, Ctrl+Alt+Z (enable ChromeVox) works even if the tray menu is open.

The reason behind calling stopPropagation there is to align the behavior with it of context menu.

SelectToSpeakEventHandler needs to take action on both Search up and Search down, I'm not sure if that's possible with an accelerator. Also, I don't think that semantically it's an accelerator, it's really a modifier.

I think it'd be possible to change the order of precedence so that SelectToSpeakEventHandler gets called earlier (PrependPreTargetHandler instead of AddPreTargetEventHandler in select_to_speak_event_handler.cc). Could we try that first and see how far that gets us?

Changing AddPreTargetEventHandler to PrependPreTargetEventHandler does not fix this, unfortunately.

Similarly, Select-to-Speak is unable to cancel mouse events before they reach ARC++, in  crbug.com/793950 . In both cases, we need to move select-to-speak earlier (or higher priority) in event handling.

Another example is in the chrome browser menu, select-to-speak doesn't work. Commenting out canceling event propagation in ui::PostDispatchAction MenuController::OnWillDispatchKeyEvent makes select-to-speak work again.

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

commit 0c0f37953a732bd7876d209fa81847eab29abb59
Author: Katie Dektar <katydek@google.com>
Date: Mon Dec 18 18:35:33 2017

Use an EventRewriter to ensure Select-to-Speak always gets key events.

The EventRewriter is able to get events before they are even passed to
the system menus, which allows Select-to-Speak to have a chance to
process key events before the menus can stop key event propagation.

This change basically refactors select_to_speak_event_handler* to
select_to_speak_event_rewriter*. It neither adds nor removes tests.

Bug:  791809 , 793950 
Change-Id: Ied4c937e0ff1bcb2c56121f048d185290f4a168e
Reviewed-on: https://chromium-review.googlesource.com/823280
Commit-Queue: Katie D <katie@chromium.org>
Reviewed-by: James Cook <jamescook@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#524748}
[modify] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/BUILD.gn
[modify] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/accessibility/accessibility_manager.cc
[modify] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/accessibility/accessibility_manager.h
[delete] https://crrev.com/40f1f1b0b1e0f44d7976cb36297076073a066124/chrome/browser/chromeos/accessibility/select_to_speak_event_handler.cc
[delete] https://crrev.com/40f1f1b0b1e0f44d7976cb36297076073a066124/chrome/browser/chromeos/accessibility/select_to_speak_event_handler.h
[add] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/accessibility/select_to_speak_event_rewriter.cc
[add] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/accessibility/select_to_speak_event_rewriter.h
[rename] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/accessibility/select_to_speak_event_rewriter_unittest.cc
[modify] https://crrev.com/0c0f37953a732bd7876d209fa81847eab29abb59/chrome/browser/chromeos/chrome_browser_main_chromeos.cc

Google Chrome 67.0.3369.0 (Official Build) canary (64-bit)
Firmware Version Google_Samus.6300.276.0
Flag enabled: #enable-experimental-accessibility-features

Works as expected on the status bar, in Wifi also works properly.

Here's an interesting side effect that's not really a bug: in the Wifi list, the ordering is changing a lot due to varying signal strength. STS will read the SSIDs in the order in which they are appearing at the time of STS reading it. That means it may appear to skip around in the tab ordering. However, it's just reacting to the re-ordering in real time sometimes even before it's visually re-ordered. The highlight remains on the correct word being spoken. Looks good to me. 

Moving from just having STS label to also having the UI>Accessibility>SelectToSpeak component to make searching easier in the future.