Update definition for single pointer

[patrickhlauke]

The definition for "single pointer" has had issues for a long time, as it mixes the idea of what a pointer is with the action(s) performed using a pointer.

I originally tried to fix this, but there was no appetite for it once 2.1 was released. However, with 2.2 and the new 2.5.7 Dragging Movement SC, the broken definition is causing actual misunderstandings/illogical non-sequiturs.

See #749 (comment) and the recent #3535 where this is once again causing a non-sequitur

Closes #3535

(this is effectively a follow-up to #809 which had disambiguated things, but the definition had since been changed further/again to reintroduce the ambiguous wording we have at this point which confuses input with action)

This would be applied to WCAG 2.1 and 2.2, unless there is a decision to only apply it to 2.2.

EDIT: Also closes #394

---

Preview | Diff

[benja11y]

The definition for "single pointer" has had issues for a long time, as it mixes the idea of what a pointer is with the action(s) performed using a pointer.

See #749 (comment) and the recent #3535 where this is once again causing a non-sequitur

Closes #3535

Preview | Diff

Not sure the new definition catches everything, such as joysticks, light pens or 'simulated' versions of pointer (think Dragon's mousegrid feature) for example. Will try to come up with a catch-all.

[patrickhlauke]

@benja11y it doesn't need to be comprehensive ... I rejigged it so it doesn't give the impression that it's an exhaustive list

[benja11y]

Changed my - to a +

[detlevhfischer]

Looks good to me.

[bruce-usab]

On deck for 1/23 call.

[bruce-usab]

From the call 1/12, in no particular order.

• @gundulaniemann preferred current definition to the change proposed.
• No one disagreed that the current definition is not very good.
• There seemed to be general consensus about adding "— such as a mouse" as having explanatory utility. But probably additional examples (as part of the defined term) are too much.
• @dav-idc noted that "on screen" could be taken too literally (as physical). Eye gaze is an example of single pointer where nothing is touched.
• @dbjorge noted that "one point at a time" could be understood as only covering the start of an interaction (e.g. mouse-down event).

[patrickhlauke]

@alastc @mbgower @bruce-usab et al ... updated the definition to incorporate some of the suggestions/feedback from yesterday's WCAG 2.x backlog meeting

[bruce-usab]

Very clean edit, thanks!

[bruce-usab]

We had significant discussion 1/19 call, but wording was not finalized. My few notes:

• SC mention of "point" can be read to mean a single pixel.
• "multi-touch scenarios" is confusing.
• AT presents as a mouse, so that is not a conflating issue.
• Some SC definitions include examples (block) which might be a good option.
• Preference is to keep definition work as copy/paste, but that can be just the first sentence of defined term.
• SC provide some context which might take some of load off the defined term. For example, 2.5.1 exception includes (undefined) term "multipoint" so it follows that "multipoint" need not be part of definition for single pointer.

[patrickhlauke]

As a possible alternative, I've moved the mention of multipoint (rather than "multi-pointer/multi-touch") into a note (following precedent set in other definitions that also include a note and/or example).

[bruce-usab]

Looks fine to me, but is normative change, so will want to highlight that for AG review.

[mraccess77]

Single point on the screen/page could be interpreted by some as single pixel (x,y) point - is this always the case?

[patrickhlauke]

@mraccess77

is this always the case?

what situations are you thinking of where this is not the case?

[dav-idc]

Single point on the screen/page could be interpreted by some as single pixel (x,y) point - is this always the case?

A single point on a screen can be made up of several pixels, such as in the case of a retina display. Hence, it's helpful to not say specifically a pixel, but rather a point.

The only case I can reasonably think of where it's not an x,y point (but not necessarily a single pixel) is in a 3D display system where it might be an x,y,z point. But I think this updated definition still covers current 3d technologies, where an x,y,z point is still delivered through a screen.

[alastc]

@iadawn this went through CFC, so needs adding as an errata. (That's been a Staff task so far, I'm not sure where it is edited?) We'll keep it on the project board until that's confirmed.

[patrickhlauke]

hurrah!

[alastc]

@WilcoFiers added on list:

This new definition seems to exclude path-based gestures from the single-pointer input. That creates a contradiction with 2.5.1. 2.5.1 explicitly says a path-based single-pointer gesture is allowed if it is essential. If single-pointer input is not path based, how can it be allowed? The second problem with it is it changes the scope of 2.5.2. If path-based gestures are not considered a single-pointer input, then using a path-based gesture on a down event with no way to abort or undo the action is now allowed. It makes this SC 2.5.2 more permissive than it used to be.

Could someone respond? (Here or on list.)

[patrickhlauke]

This new definition seems to exclude path-based gestures from the single-pointer input

I don't see how, to be honest. The new definition disentangles the fact that the term defined was the input (as in the mechanism), not the gesture (tap, swipe, etc) itself, because the previous definition was what was causing the non-sequitur in #3535

a path-based gesture can still be reliant on a single-pointer input (the mechanism of input, i.e. the finger, the mouse, the stylus), and nothing in the new definition contradicts that - unless you interpreted "input" as being the gesture rather than the mechanism (but under that interpretation, we had that contradiction of #3535). and the pointer events spec itself defines input as the mechanism too.

[dbjorge]

Discussed this with @WilcoFiers; the confusion seems to be coming from the use of the term "at a time" in the new definition. Wilco suggested that an extra note/examples clarifying which actions a single pointer can perform would have helped clarified; perhaps we can reconsider adding something like this?

<p class="example">Clicking, double-clicking, long-pressing, and dragging a slider are operations that can be performed using a single pointer.</p>

[alastc]

Hi Dan, we had previous iterations (and #809) that included interactions such as clicking, but it moved the focus to the interactions rather than the input type, which seemed to cause more confusion.

I'd also note we previously added a paragraph to the pointer-gestures understanding doc:

Single pointer operations include taps and clicks, double-taps and double-clicks, long presses, swiping, dragging, and path-based gestures. Gestures such as "pinch to zoom" or two-finger swipes are multipoint gestures, as they require two or more pointer inputs - in this case, two fingers on a touchscreen.

[bruce-usab]

Discussed 9/13, TF members affirmed okay as it. Patrick offers to do another close review, by 9/17 AG call.

[patrickhlauke]

@bruce-usab

So this PR has already been merged - making tweaks to it would need a separate new PR. Before proceeding with that, and seeing @alastc's comment above #3536 (comment) about not adding in an extra note giving examples of gestures that can be performed with a single pointer, I'm wondering if changing just the start of this from

an input that only targets a single point on the page/screen at a time – such as a mouse, single finger on a touch screen, or stylus

to

an input mechanism that only targets a single point on the page/screen at a time – such as a mouse, single finger on a touch screen, or stylus

(adding the word "mechanism" after input, to make it clear that this is explicitly what this is referring to, rather than "input" in the sense of the "gesture") would help clarify things.

[patrickhlauke]

Made the small PR just adding "mechanism" here #4070 @bruce-usab @alastc

[mbgower]

Reviewed and finalized on Sep 20 TF call with revisions to https://github.com/w3c/wcag/pull/4070/files.
Returned to the Errata for CFC column.