Communicating between the WPT test window and a separate application on the client

Hi!

The ARIA Working Group is investigating various ways to automate the
testing of ARIA - which requires testing the accessibility api and its
communication with assistive technologies (AT) on a bunch of platforms.
Obviously, this is a bit of a challenge.  The current thinking is that a
fake AT can be provided on each platform.  The fake AT is started by the
tester (or test automation environment) prior to starting a test run.  Once
it is running and has found the test window, it will capture the
accessibility tree and events as the tests set up and manipulate the DOM.
Simple enough.

Except, of course, for getting the information from the fake AT back into
the test window.  Consider the following (terrible ASCII art) diagram:

 WEB BROWSER   <----->  CHILD WINDOW
 MAIN WINDOW            FOR INDIVIDUAL TEST
                              ^
                              |
                            MAGIC
                              |
                              v
                         LOCAL AT SHIM


The "MAGIC" is where I am playing right now.  Here are some of my ideas:

   1. Shim is passed a URI on the WPT server on startup (or finds the URI
   when it finds the test window). Communicates with it through a websocket,
   and the window in which the test is running communicates with the same
   websocket endpoint.  Data is relayed that way.  This seems the most
   portable to me.
   2. Shim runs a simple HTTP listener.  Child window communicates with
   that using HTTP (websocket or simple HTTP GET) on localhost.  This requires
   implementing a messaging stack... which doesn't feel very easy on every
   platform but is probably do-able.  It might also violate CORS stuff, but
   again - do-able.
   3. Rely on some sort of native messaging that is platform specific.
   This doesn't feel scalable to me.  It would also mean modifying the WPT
   part of this any time we wanted to add another platform that had a
   different native messaging capability.
   4. Use a ServiceWorker in some magical way that I probably don't
   understand.  Feels like a steep learning curve.  Also, they don't seem to
   be widely supported yet.

My hope is that some of you have already thought about a similar problem
(there is a native application running on the platform under test that
needs to send messages into the test in order to evaluate success or
failure).  So... any ideas?
-- 
Shane McCarron
Projects Manager, Spec-Ops