APA WG feedback on Input Events

The Accessible Platform Architectures WG has reviewed the Input Events 
specification (https://www.w3.org/TR/input-events/) and has the 
following comments:

== Substantive ==

1. From an accessibility perspective the following would be valuable:

- A notification to ATs that functions like text insertions were 
completed so that positive reinforcement could be provided to the user.
- A programmatic way for alternate input solutions to drive some of the 
changes would be helpful. For example, an AT might want to insert the 
text now that this can be done in a device independent way. Some of this 
may be provided for in UI Automation (Windows platform) but are they 
provided on others?

== Editorial ==

Editorial comments are less critical to handle on a WG-to-WG level, but 
our participants thought they were relevant enough to send.

1. This text is not clear:

The DataTransfer object's drag data store item list 
<https://html.spec.whatwg.org/multipage/interaction.html#drag-data-store-item-list> 
contains one entry with the draf data item type string 
<https://html.spec.whatwg.org/multipage/interaction.html#the-drag-data-item-type-string> 
|"text/html"|, whose kind 
<https://html.spec.whatwg.org/multipage/interaction.html#the-drag-data-item-kind> 
is /Plain Unicode string/, and whose data is a HTML representation of 
the content that is in the clipboard, in the kill buffer 
<https://www.w3.org/TR/input-events/#dfn-kill-buffer>, to be dropped or 
otherwise the content that is to be added. [HTML-LIVING 
<https://www.w3.org/TR/input-events/#bib-HTML-LIVING>]

Are you equating the kill buffer with the clipboard? It looks like you 
are missing an “or” as in “ or in the kill buffer”.

2. Also, you refer to HTML-LIVING. Wouldn’t you be referring the W3C 
spec. vs. the WhatWG version? This is in multiple locations in the spec. 
APA notes this because of the better focus on accessibility within the 
W3C HTML standard.

3. Another seemingly editorial issue is this text:
"A user agent <https://www.w3.org/TR/input-events/#glossary-user-agent> 
/MUST/ dispatch <https://www.w3.org/TR/uievents/#dispatch> [UI-EVENTS 
<https://www.w3.org/TR/input-events/#bib-UI-EVENTS>] this event 
immediately after the DOM has been updated due to a user expressed 
intention to change the document contents which the browser has handled.”

This does not read properly. Maybe UI-EVENTS should come after “this event”

4. The beginning of this document should state that this is a solution 
solely targeted at contenteditable elements in HTML vs. being a general 
device independent solution. This will not work for SVG.

For APA,
Michael Cooper, staff contact