Re: PFWG comments on Touch Events, 24 Jan 2013 version

Hi - the URI the PFWG has accepted for this resource is:

http://www.w3.org/WAI/PF/wiki/Touch_Events_Accessibility_Mapping

There is very basic placeholder content there right now. We will come up
with a plan to populate this page with preliminary data in the near
future. Hopefully what is there is enough for you to publish.

PFWG discussion of this is archived at
https://www.w3.org/2013/03/06-pf-minutes.html#item02 (Member-only link).

Michael

Arthur Barstow wrote:
> Hi Michael, PFWG,
>
> We now have sufficient implementations for this spec to advance to
> Proposed Recommendation [ImplReport]. As such, to prevent your comment
> from blocking our PR, we would like to get closure on your comment as
> soon as possible (our LC comment tracking document is [LC-Comments]).
>
> I propose adding the following text as the last paragraph in section 1
> of the spec:
>
> [[
> The Protocols and Formats Working Group created a non-normative
> document that includes a mapping of hardware events (e.g. keyboard
> events) to touch events. For more information see [@TBD].
> ]]
>
> Please feel free to supply your own text rather than the above.
>
> We can use something in WebEvents' URL space (e.g.
> <http://www.w3.org/2010/webevents/wiki/Mapping>) as the URL for the
> reference or we will use whatever URL you give us.
>
> When can we expect you to either accept our text or for you to supply
> your text?
>
> -Thanks, ArtB
>
> [ImplReport] <http://www.w3.org/2010/webevents/wiki/TEv1ImplReport>
> [LC-Comments]
> <http://www.w3.org/2010/webevents/wiki/TouchEvents-LCWD-24-Jan-2013>
>
>
> On 2/15/13 9:15 AM, ext Arthur Barstow wrote:
>> Hi Michael,
>>
>> Given the information you want to add is non-normative, I prefer your
>> suggestion the Web Events spec include a link to this additional
>> information, especially since that will facilitate the evolution of
>> the information (without having to change the Web Events spec).
>>
>> How about I can create a wiki document under WebEvents' wiki <>? If
>> you don't like that idea, then we can use whatever you prefer.
>>
>> Also, can you please give us a rough estimate on when you expect to
>> have information available?
>>
>> (After we see your information, we can work together to determine how
>> the Web Events should link to it e.g. which section.)
>>
>> -Thanks, Art
>>
>>
>> On 2/13/13 12:17 PM, ext Michael Cooper wrote:
>>> 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/>
>>>
>>
>>
>

-- 

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