[Bug 24786] ACTION-64: Propose a non-normative note re the keyboard compat issue

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24786

--- Comment #5 from Patrick H. Lauke <redux@splintered.co.uk> ---
In our original discussion about whether or not kbd/kbd-like interfaces should
also be considered, one of the arguments against was that tabbing from one
focusable element to the next and/or activating with keyboard does not have
actual coordinates to pass along.

Doing some testing with VoiceOver/iOS (which fakes touch and mouse compat
events when the user moves the screenreader's focus or activates) and old Opera
(Presto) Spatial Navigation (which moves a visual focus on screen, again to
focusable elements, but allowing the user to move up/right/down/left and moving
the focus according to the visual rendered layout), it seems though that
coordinates are, in fact, passed along (in the case of VO/iOS, it's the
calculated center of the element, while Opera takes the top-left coordinates).

So, although I understand the distinction here is more "philosophical" (is
on-screen focus indication, which is somehow moved from element to element, a
"pointer"?), the one distinguishing factor (a pointer actually has coordinates)
is moot.

Anyway, not going to try and push further to include kbd as an actual pointer
(with its own event.pointerType and spec'd behavior for user agents), but in
light of this I *will* say that Rick's addition about (continuous) co-ordinates
is a red herring...it's up to the user agent to decide *if* they want to fire
pointer events in response to kbd-like movement (as I understand Opera are
planning to do when they reintroduce Spatial Navigation feature, particularly
on their TV platform). 

The short outcome, though, is that I propose this text (which removes the red
herring again, and still leaves it open to UAs to do what they think is best
when it comes to kbd/kbd-like inputs) as a NOTE in the introduction, after the
"An additional key goal..." sentence, as a highlighted block:

While this specification defines a unified event model for a variety pointer
inputs, this model does not cover other forms of input such as keyboards or
keyboard-like interfaces (for instance a screenreader or similar assistive
technology running on a touchscreen-only device, which allows users sequential
navigation through focusable controls and elements). While user agents may
choose to also generate pointer events in response to these interfaces, this
scenario is not covered in this specification. Authors are encouraged, where
possible, to provide equivalent functionality for these forms of input by
including explicit keyboard event handling or responding to higher-level events
such as <code>focus</code>, <code>blur</code> and <code>click</code>. See WCAG
2.0 Guideline 2.1 for further details [link to
http://www.w3.org/TR/WCAG20/#keyboard-operation]

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 3 March 2014 00:04:15 UTC