W3C home > Mailing lists > Public > public-apa@w3.org > March 2017

Re: APA WG feedback on Input Events

From: Janina Sajka <janina@rednote.net>
Date: Wed, 29 Mar 2017 11:27:38 -0400
To: Johannes Wilm <johannes@fiduswriter.org>
Cc: Michael Cooper <cooper@w3.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>, APA WG <public-apa@w3.org>
Message-ID: <20170329152738.GB10635@opera.rednote.net>
Hello, Johannes:

I want to acknowledge your response on our Input Events comments and let
you know that we will do our best to respond to your questions soonest.

Meanwhile, a question for you. We note there're now two now publications
for Input Events, a Level1, and a Level2. Can you give us a quick
summary of how to understand these? Do these, for instance, cover the
same ground as the spec we reviewed, but now broken into two parts with
separate implementation expectations? Any guidance would be very
helpful, so thanks in advance!

Janina, APA Chair

Johannes Wilm writes:
> 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


Janina Sajka,	Phone:	+1.443.300.2200
		Email:	janina@rednote.net

Linux Foundation Fellow
Executive Chair, Accessibility Workgroup:	http://a11y.org

The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI)
Chair, Accessible Platform Architectures	http://www.w3.org/wai/apa
Received on Wednesday, 29 March 2017 15:28:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:23:02 UTC