David reverted the issue that broke this, so I'm morphing this into the reason it broke as that still needs to be fixed. My suspicion is the struct traits for serializing a KeyEvent are wrong, so that when ChromeVox gets the event it gets the wrong event and doesn't navigate.

Looks like I was wrong on the reason.

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

commit 1946cf1f31143f7ec323a2e9bc584985def39368
Author: Scott Violet <sky@chromium.org>
Date: Wed Mar 14 17:00:04 2018

chromeos: changes Window Service to only install EventRewriter in mash

In mus-mode chrome/ash installs the EventRewriterChromeOS, so the
Window Service shouldn't install it too. The Window Service installed
it in such a way that sticky keys wasn't present, which meant the
EventRewriterChromeOS in the WindowService would change the event so
that when the EventRewriterChromeOS in chrome saw the event it didn't
match.

BUG= 821592 
TEST=covered by tests

Change-Id: Ib5472243bdd0365cd0fc75b31f31faf2aca4e03a
Reviewed-on: https://chromium-review.googlesource.com/962714
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Commit-Queue: Scott Violet <sky@chromium.org>
Cr-Commit-Position: refs/heads/master@{#543106}
[modify] https://crrev.com/1946cf1f31143f7ec323a2e9bc584985def39368/services/ui/ws/display_manager.cc