Scope to look at keyboard/d-pad controls?

This may be out of scope, but just wanted to get a feel for this...

As great as it is to see that with Pointer Events devs don't need to 
fork their code to handle mouse/touch/stylus differently, one aspect 
that still requires double work (which a lot of devs sadly still don't 
consider) is keyboard access.

Often, the amount of work necessary to cover both "mouse" and keyboard 
isn't that great - this has been discussed at length in accessibility 
circles for aeons, but usually simply involves doubling-up :hover styles 
to also kick in on :focus, or doubling-up mouseover/mouseout to also 
fire on focus/blur (though this is not always enough...for instance, 
with CSS dropdown menus, the way :hover can be added to the parent 
element which contains the submenu items means that the menu remains 
visible even when the user mouses into the menu...while for keyboard 
users, :focus is usually set to the "header" of the menu that can 
receive focus, and as soon as the user TABs away into the menu items, 
:focus is lost again).

The issue isn't purely a "desktop with keyboard" one, of course. Same 
problems arise with "Web on TV" setups with D-Pad controls, and even on 
ostensibly "touch-only" platforms running assistive tech (e.g. a 
touchscreen-only Android smartphone/tablet with TalkBack).

So, I wonder if perhaps Pointer Events could somehow help here and also 
cover keyboard interaction. Not exactly sure what I envisage, in detail, 
but as a start I could imagine:

- as the user moves keyboard focus around, fire the relevant 
PointerOver/PointerEnter not just on the focusable element that they 
landed on, but also any other parent elements they may have "crossed". 
E.g. if focus was initially on a direct child of <body>, and the next 
TAB gets them in a <div><p><a ...></a></p></div> then fire the events on 
the <div>, the <p> and the <a>. If the next TAB then moves to a sibling 
paragraph inside the same <div>, only fire PointerLeave/PointerOut of 
the <a> and the original <p>, then PointerOver/PointerEnter just on the 
sibling <p> and the next <a> that they focused on. sorry, 
convoluted...but does that make any sense?

- add a new pointerType for this...something generic enough to cover 
keyboard, d-pad, etc

Feel free to tell me that's crazy talk. Just thinking that it would be 
nice to finally have a single, unified input method, rather than still 
relegating keyboard/sequential/spatial access to require additional 
handling to make stuff accessible/usable.

P
-- 
Patrick H. Lauke
______________________________________________________________
re·dux (adj.): brought back; returned. used postpositively
[latin : re-, re- + dux, leader; see duke.]

www.splintered.co.uk | www.photographia.co.uk
http://redux.deviantart.com | http://flickr.com/photos/redux/
______________________________________________________________
twitter: @patrick_h_lauke | skype: patrick_h_lauke
______________________________________________________________

Received on Monday, 18 November 2013 17:02:17 UTC