Re: APA WG feedback on Input Events

Dear Michael and the rest of the APA WG,

thanks for waiting while we were figuring out how to split our spec.

On Fri, Feb 10, 2017 at 8:39 PM, Michael Cooper <cooper@w3.org> wrote:

> 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.
>

I assume that this would be an event automatically triggered by the browser
when it is done with its DOM changes. We would then need to trigger such an
event manually when the JavaScript is doing the DOM changes, right?

This seems a bit problematic in the basic version of the spec in level 1
(the Chrome version): This version will let the browser do a lot of the
DOM changes, but it then expects for the JavaScript to revert the changes
afterward if the JavaScript wants to do something else instead. The problem
here is that the browser will think that the required DOM changes have been
executed already, when in fact they haven't.

Anyone with a suggestion of what to do with this?


> - 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?
>

The way I read this, you are saying that you would like to have some more
clarity on how browsers will integrate with AT tools to let them trigger
some or all of the various beforeinput events. Until now, we have not
specified what types of inputs the browsers work with or what inputTypes
they support. So for example Edge may decide not to connect joysticks with
contenteditable, and so joysticks cannot cause any DOM changes and
therefore no beforeinput events are ever triggered when the user uses a
joystick. Apple, on the other hand, may decide that joystick clicks change
the for- and background color of the currently selected text in a random
way, so on Mac OS X, joystick clicks will cause the corresponding
beforeinput events.

Are you suggesting that we should start saying that certain input
mechanisms and inputTypes must be supported?


> == 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”.
>

The "or" has been added.

>
> 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.
>

There has been a discussion on whether to link to WhatWg or W3C versions of
specs earlier. I don't mind linking to the W3C version instead, but do
Domenic Denicola and others agree?


>
> 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”
>


The point is that the term "dispatch" is defined in the UI Events spec,
which is why it is linked like that. But I can move the link if that still
makes sense.


> 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.
>

How about changing the sentence "This document describes editing related
additions to 2 events - Input and beforeinput which are described in the UI
events spec [UI-EVENTS]." to something like

"This document describes editing related additions to 2 events which are
triggered within editing host - Input and beforeinput which are described
in the UI events spec [UI-EVENTS]. Editing hosts can be elements with the
contenteditable attribute set, textareas, or input elements of with the
attribute "type" set to "text"".



>
> For APA,
> Michael Cooper, staff contact
>

Thanks a lot for your thorough review!



-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org