RE: Pointer Events types and keyboard/keyboard-like interfaces?

+ www-dom, Gary Kacmarcik, and Travis Leithead who have been making great improvements on keyboard events over in Web Apps WG

On Mon, Jan 6, 2014 at 8:06 AM, Bruce Lawson <bruce@brucelawson.co.uk> wrote:
> Patrick said,
>
> "I fear that as we move over to pointer events, the same thing will
> happen - devs just relying on pointer events as being the "umbrella"
> events model that catches "everything"...and still forgetting to address
> keyboard/keyboard-like interactions."
>
> I think this is a legitimate fear. I *want* pointer events to be an umbrella events model that catches everything, and from feedback I've received, developers do, too.
>
> However, we know that developers forget about keyboard access already (and other accessibility concerns, such as alternate text for images) so I worry that as pointer events catch on, there will be more accessibility problems.

While I agree developers commonly forget about keyboard access, I don't think pointer events are going to make the situation worse. With respect to keyboard interaction, they work no different than what we already had with mouse events.

> (And, FWIW, there seems to me no difference between "pointing" at something with a mouse, a finger, a pen or by tabbing to it).

If all you're using pointer events for is to essentially select/click an element, sure. But for most scenarios that I see pointer events used in, the keyboard input wouldn't be compatible with the code used for true pointing devices. Just a few examples (each using pointer events today) to consider that don't work if all you can do is select an element:

Bing/Google Maps (pan/zoom map)
Flipboard.com (swipe page turns)
Atari.com/arcade (interactive canvas games)

While some pointing devices have coarser precision (e.g. touch), these devices all point on a coordinate-based input model whereas keyboard toggles on a focus ring style model. There are key differences to those models that make me skeptical that sites would share code between them.  I believe the result would then be that, at best, many sites would need to 
    if(e.pointerType=="keyboard") { //do something special} 
and, at worse, would continue to forget about keyboard--thus introducing odd/broken behavior when a keyboard is used because it triggers their pointer code paths that weren't designed with keyboard in mind. If they're doing the former, then it's probably no harder (perhaps, easier) to use the existing keyboard events. 

It's possible we might get some accessibility wins from firing pointer for keyboard, so it's certainly worth the exploration. But I like Rick's suggested approach of investigating this through polyfills as all the primitives in the platform to build this behavior should already be there.

Received on Monday, 6 January 2014 19:01:26 UTC