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

Shane thank you again for getting this conversation started and your interest in getting ARIA testing as part of WPT.
Just for clarification.  The “fake AT” is basically a application that exposes information about a platform specific accessibility API as WPT or some other tool exercises a ARIA test page.   So the application needs to look the accessibility tree and related events and get that information back into the browser for comparison with expected results for us to utilize the WPT framework to its fullest extent.

Jon


From: Shane McCarron [mailto:shane@spec-ops.io]
Sent: Friday, July 15, 2016 8:43 AM
To: public-test-infra <public-test-infra@w3.org>; public-aria-test@w3.org
Subject: 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