Re: Accessible interactions with simple switch devices

Hi, Steve-

Thanks for writing.  We are just now ramping up the group, so expect to 
see more in the coming weeks.

Regarding the scope of the group's work items, we have a deliberately 
narrow scope for the charter for 2 reasons:

1) We want to stay focused in order to complete the touch and 
intentional events in a timely fashion;

2) There is very likely some Intellectual Property around the area of 
touch interfaces, and we are treading very carefully to make sure we can 
best serve all our constituents.

So, while it's not possible right now for us to create specific events 
for switch devices, some aspects of those devices should work with the 
high-level abstract "user action" or "intentional" events.  If that 
should prove to be inadequate, we can certainly revisit the issue when 
our group comes up for rechartering in 2012.

If you could summarize precisely what problems you ran into when trying 
to adapt a switch interface to DOM events, that would go a long way 
toward making sure we consider that when defining intentional events. 
It's quite possible that support for switches will simply come as a 
natural consequence of the model.

Regards-
-Doug Schepers
W3C Team Contact, SVG, WebApps, and Web Events WGs

Steve Lee wrote (on 10/29/10 5:30 PM):
> I'm very pleased to see this work group starting as it's a real hot
> topic ;-) I'm coming at it from an open accessibility angle with a
> keen interest in accessibility of mobile devices and especially web
> apps. So it's very good to see accessibility issues mentioned
> explicitly in the
> charter.
>
> One observation is that the WG name of 'Web Events' indicates a wider
> scope that mentioned in the charter. In particular I'm interested in
> interactions for people with motor impairments who often use simple
> switch devices and scanning interactions. While these are very
> inefficient and we're desperate for innovation, they are currently
> popular along with alternatives like eyepointing which map to pointer
> events as far as browsers are concerned. Switch + scanning usually
> involves an intermediate selection UI that then maps to standard
> events but there are alternatives such as the direct scanning approach
> using a11y APIs that we explored in Jambu [1].
>
> I also believe there is a case for handling switch events directly in
> the wep app as it allows greater flexibility. For Maavis [2] we
> implemented scanning in the app itself. Maavis is currently a Mozzila
> XUL rich client application but we want make it a web app and one of
> the issues is handling switch events. I tried overriding standard DOM
> events but unless I wanted to build a custom Firefox with enhanced
> event model it was not possible to support what was needed. So another
> mechanism is used, outside DOM events. This obviously won't be
> possible in a web app.
>
> Currently such devices are not 1st class as far as platforms are
> concerned, much as with touch interfaces where until very recently.
> They usually appear as USB HID devices, for example on WIndows they
> appear as games controllers. Accordingly Browser do not support them
> directly either.
>
> Any way the 'ask' I leading up to is - can simple switch device events
> be included in scope for this WG?
>
> On another topic I like the events abstraction layer model and think
> it makes sense - but as always the test will come with implementation
> and use. Interestingly a group us starting thinking along similar
> lines for the accessible desktop APIs a while back [3].
>
> I'm glad to be involved with this WG
>
> 1: http://jambu.fullmeasure.co.uk/
> 2: http://maavis.fullmeasure.co.uk/
> 3: http://groups.google.com/group/osk-ng
>

--

Received on Tuesday, 16 November 2010 23:12:44 UTC