W3C home > Mailing lists > Public > public-webevents@w3.org > January to March 2013

PFWG comments on Touch Events, 24 Jan 2013 version

From: Michael Cooper <cooper@w3.org>
Date: Wed, 13 Feb 2013 12:17:59 -0500
Message-ID: <511BCAC7.2020307@w3.org>
To: public-webevents@w3.org
CC: WAI Liaison <wai-liaison@w3.org>
The Protocols and Formats Working Group has reviewed Touch Events 1.0
Working Draft of 24 January 2013
http://www.w3.org/TR/2013/WD-touch-events-20130124/ for accessibility
issues. The finding of the group is that the events don't inherently
impact accessibility in any particular way, but they do define a certain
class of input events (touch) that not all users may be able to use. We
do not think it is in scope of the Web Events Working Group to address
this directly. However, we would like to request that informative
content be added to alert implementers and suggest actions they may
take. In this comment we outline the general structure of this content;
if you accept the proposal in principle, we can work with you on a
reasonable timeline to prepare the specific content. We are sending it
in this manner in order to make sure to log the comment by the due date,
which would not be possible if we take time to develop the complete
proposal first.

The issue of events of one type not being available for all users is
already widespread with mouse events. For many years now, user agents
have provided a workaround of sorts. Applications listen for the "click"
event in order to actuate the user interface. As long as the control is
focusable, keyboard users can navigate to the control and press the
Enter key. The user agent actually generates a click event in response
to this key action, so the web application requires no special coding to
handle keyboard users, and accessibility of the application is maintained.

The PFWG believes this type of solution could be applied to Touch events
as well. The proposal is to provide a table that maps other hardware
events (particularly keyboard events, but possibly others) to Touch
events. User agents that implement this mapping would fire the
appropriate Touch event whenever the other hardware event was received.
This would provide transparent accessibility support for web applications.

The proposal is that this be *informative* content only, perhaps in an
appendix or other location of your choice. User agents would not be
required to implement this mapping, and the timeline of progression to
Recommendation should not be affected. The accessibility community would
separately advocate with user agent developers that these mappings be
implemented.

The specific mapping suggestions require further exploration. Not all
Touch events would have a corollary on other input types. But it should
be possible to come up with a small set of mappings that allows the
majority of applications that use Touch Events to be accessible without
special coding.

For the PFWG,
Michael Cooper

-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>
Received on Wednesday, 13 February 2013 17:20:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 13 February 2013 17:20:11 GMT