aleventhal / js2at Goto Github PK

It should be easily usable with packaging systems, and includable from a gist.

Share location of the fake Docs cursor with pathways.

Right now, only one AT is supported by the native messaging host.

Each AT probably should have its own port.
To do this, we could make each AT a TCP server, and they could add a file to a directory when they want to a connect. The native messaging host could discover these files and read the port number from there.

According to this announcement, Python 2 will no longer be supported.
We should convert our scripts and installation docs to be based on Python 3.

Each message should provide a pageId or something similar that the AT can also discover using an accessibility API, so that it can tie it's various documents explored through a11y apis to the same js2at-providing document.

Users should be asked for permission when a web page attempts to connect to js2at.

• User should be given specifics for what the js2at api wants to do and why. This information could be bundled in localized schema description files with the same root name.
• Multiple requests should be put together in one
• Web page does not need to be informed that the user said no, but it would simply not get any requests.
• The observerAdded command would not be sent to AT until user said yes.
• Open question: should the question even be asked if there is no AT attempting to listen? Probably not.
• Chrome should remember the permissions on a per-page basis.

The extension currently will not run in Firefox, and need to be ported.

• Docs for AT developers
• Docs for infrastructure -- what does it do?
• Docs for page authors

Need to support a number of types of errors:

Error messages sent to AT:

• Unsupported request type
• Unsupported property
• Exception handling request
• Cancelled from timeout

Error messages sent to AT and content

• Request or response does not validate

Create a fake editor using and use js2at to expose where the caret is.

Ensure that we refer to subschemas within a schema

Support option to load schemas and validate messages.
Another option indicates what to do with errors: reject or just log

The following modules could benefit from unit tests:

• Native messaging host
• Extension
• Polyfill

The following line is currently required in order for the JSON validator to function:
"content_security_policy": "script-src 'self' 'unsafe-eval'; object-src 'self'",

Options:

• Try to run the validator in a sandboxed iframe. Check this out:
  https://developer.chrome.com/extensions/sandboxingEval
• Find a validator that doesn't have that problem. Both djv and ajv required unsafe-eval. Not too many good options. Try z-schema?

Having a dependency on Python is not ideal on Windows where Python is not shipped by default.

We could try py2exe, or just rewrite in C++ or another language that compiles to a small executable.

Add compatibility to the ChromeOS magnifier in order to be able to show an end-to-end demo of caret tracking in docs.

Since we can't use the native messaging messaging api to communicate with ChromeVox, we should just open an ordinary port.

Ideally, ChromeVox would be able to bundle js2at functionality without requiring the additional extension. However, this would require js2at to be more mature and ready to be bundled with Chrome.

So for now, let's just open up the additional port.

• Run chrome --user-data-dir=/tmp/someuniquedirname --load-extension=path/to/extension --no-first-run http://localhost:8000/test-pages/headings-test.html
• Connect to the js2at port
• Look for observerAdded
• Send a request and get response, test response
• etc.

• Import libraries used, e.g. ajv and zmx
• Copy internal schemas to extension folder, which would allow all the schemas to be under one schema folder

It should be clear what messages are system-generated, such as 'observerAdded'.
We could add a field, like "systemGenerated": true
Currently I actually prefer a prefix, like $
type = '$systemGenerated' -- this will help delineate these inside of message handling code.

If AT launches and observers were previously added in the page, fire them so that the AT knows they're there.

Get web API reviewed sooner rather than later.
We don't want people to say we're not like other web APIs, or bring up other concerns late.

Each browser will spawn a broker (native messaging host + tcp client).
Each AT needs to inform all current/future brokers that they are listening/interested in js2at messages.
@zork