How should canvas EditContext be made accessible? #139

See also: #136. It's not clear how exactly canvas-based EditContext editors should be made accessible to assistive technologies such as screen readers.
In theory, the EditContext.text could be exposed to screen readers, however, I don't know if that's a good idea since it's missing information about formatting and structure (paragraphs, links, etc.). So some kind of alternative content is needed. However, screen readers often announce the selected text, so that information needs to be exposed somehow. Web apps could use the SpeechSynthesis API to announce things directly, but that requires a lot of extra work to rebuild all the functionality that already exists (using arrow keys to change what is being announced, etc.) and wouldn't necessarily work the same as the software the user is used to.

So I'm thinking, perhaps the best solution is to synchronize the DOM selection in the alternative content with the selection in the EditContext, while keeping the EditContext focused. Something like this: https://ltenmoz.github.io/editcontext-canvas/index.html. However, this seems to have some issues. For example, when using NVDA on Windows, the selection isn't announced when new text is selected. Also, if PageUp/PageDown is pressed, the DOM selection leaves the editor (on Chromium) since it's not preventDefaulted. So if this is the correct approach, browsers need to

• Ensure that screen readers interact well with the selection being moved by scripts with an EditContext editor focused.
• Disable selection moving shortcuts for canvas EditContext, in case there are some that the web app doesn't preventDefault (so that the selection in the alternative content doesn't get out of sync with the selection in the EditContext)

Another potential issue: WebKit and Chromium don't lay out canvas fallback content, which is an issue for assistive technologies which need to know the position of the text. Not sure what the best solution is there.