W3C home > Mailing lists > Public > public-apa@w3.org > November 2016

Action Rich to review Input Events spec.

From: Rich Schwerdtfeger <richschwer@gmail.com>
Date: Thu, 3 Nov 2016 11:51:11 -0500
Message-Id: <95E0DA4D-5013-4B2C-8C76-F586B5060024@gmail.com>
Cc: Mike Cooper <cooper@w3.org>
To: Accessible Platform Architectures Working Group <public-apa@w3.org>
https://www.w3.org/TR/input-events/ <https://www.w3.org/TR/input-events/>

Thank you for the opportunity to review the specification. Device independent interaction is very useful for accessibility making this work very important. However, the spec. does not address how assistive technology can leverage these device independent events. 

Some of these comments are editorial but now that we have device independent interaction it would be good to define mappings cross platforms to drive the same functionality from accessibility API. We have an HTML-AAM but these higher level events for command and control are not covered. 

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. I would think not. 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? I see this in multiple locations in the spec. 

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.  I would think 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. 

5. 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. I assume that some of this is provided for in UI Automation (Windows platform) but are they provided on others. 

Best,

Rich

Rich Schwerdtfeger
Received on Thursday, 3 November 2016 16:51:49 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 3 November 2016 16:51:50 UTC