I think this is fine.  We might want to say explicitly "here, a pointer is defined as an input device that has precise (continuous) co-ordinates".

Incorporating Rick's suggestion (though this makes the note a big longer and complex, of course) and changing "multiple" to "variety", just to avoid confusion (e.g. multiple pointers as discussed elsewhere):

"While this specification defines a unified event model for a variety pointer inputs (where a pointer is defined as an input device that has precise/continuous coordinates), 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]"

Created attachment 1442 [details]
VoiceOver/iOS "faked" touch/mouse events have coordinates

Created attachment 1443 [details]
Opera (Presto) Spatial Navigation "faked" mouse events have coordinates

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]

Ended up being a bit longer than before, but I hope I've captured Rick's thoughts from the discussion here as well. I split it into two paras now, both of which should be wrapped in 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.

In the first instance, authors are encouraged, to provide equivalent functionality for all forms of input by responding to high-level events such as <code>focus</code>, <code>blur</code> and <code>click</code>. However, when using low-level events (such as Pointer Events), authors should ensure that all types of input are supported. In the case of keyboards and keyboard-like interfaces, this may require the addition of explicit keyboard event handling. See <a href="http://www.w3.org/TR/WCAG20/#keyboard-operation">WCAG 2.0 Guideline 2.1</a> for further details.

I like this.  It's long, but I do think it's an important point (especially due to the implication on accessibility which is often overlooked).  Minor nit: "authors are encouraged, to" probably shouldn't have a comma.

Works for me too as a non-normative note. Good info for authors.

happy with RB's tweak. good catch

Spec updated per resolution
https://dvcs.w3.org/hg/pointerevents/rev/096ed744a82e