* Present:
+ Marco & Michael
* Getting a11y / typing merged
+ problem is that we update our contenteditable to be something that is old
+ a latency issue for some connection
+ screen-reader can read character at the old position.
+ can start skipping – reality etc.
* Use cases
+ when you type quickly – the screen reader should read it properly.
+ typing print-able keys, the problem doesn’t occur.
+ we type inside the contenteditable; doesn’t create an issue for this
+ even if the keystroke has a high latency.
+ problem focused on navigating text with the arrow keys
+ even if we don’t prevent default – so cursor is really moved …
+ if we keep moving the character back – the screen reader can’t handle this
+ starts giving the same key twice.
+ the auto-repeat on the key is quicker than the latency ...
+ if auto-repeat is 250ms need 50ms round-trip latency
* Solution
+ allow keyboard position to move inside the hidden contenteditable
+ caret changed messages we receive while we move, are not applied but stored
+ as soon as a key different from left/right tab is pressed
+ cursor position is updated to stored value.
+ can we do this on key-up ? … (Michael)
+ how do we handle wrap-around ? - need to update the paragraph.
+ we prevent this at start/end if pressing left/right arrows (Marco)
+ updating with the mouse etc.
+ problem when we un-select something with left/right arrow keys
+ position of cursor is not correct.
+ solution is almost complete and passes all the cypress tests
except for selection – failing 8/40 tests there.
* Concerns
+ want to restore position with a timeout, but check if there is
a key-down related to left/right arrows.
+ if didn’t create – setup a new timeout.
+ if restoring content on a key-up: we can have a key-down that races.
+ some events still coming.
+ autocorrect – is a bit of a pain / problem … eg.
“:^alpha:<space>” which maps to ᵅ or 
this changes the content of the paragraph – so is not skipped…
+ testing overtyping of selections etc.
* Timestamps on events:
possibly the core processes events asynchronously, so we could get out of step there too.
Still matching a timestamp from the client back to the server and tracking it per view, with a cursor update associated with that would be nice.
* We think we should be eventually consistent by just delaying these messages sometimes.
* This is the same as we do for composition events we don’t update contenteditable when doing that – since it aborts composition – same as for non-a11y input.
* Table stuff …
+ Seems – reading NVDA – that the problem is in chromium and/or our understanding of that.
+ putting some debugging breakpoints around the place is prolly the way ahead here in chromium.
* Editeng / shapes / impress:
+ no joy with shapes / impress yet … not yet started.