WCAG 2.2 Pointer Target Spacing

[alastc]

This branch imports the Pointer Target Spacing success criteria from the google doc.

You can preview the:

• Understanding doc (and SC text)
• Technique

The last survey, and last minutes.

---

Preview | Diff

[JAWS-test]

I have 3 questions, the answers to which, in my opinion, cannot be found in the Understandig at present and which could possibly be supplemented:

• Exception enlarge: Would this also include browser zoom, which according to SC 1.4.4 has to be supported up to 200% anyway (if so, would targets with 22x22 px be sufficient if zoom up to 200% works)?
• Is the SC only intended for mobile devices that are operated with fingers? Or also for desktop devices, where mouse or pen operation may also be difficult for people with tremor if the targets are too small?
• Does this also apply to standard elements that are rendered by the browser? E.g. for <option> elements within a <select> dropdown list?

[alastc]

Hi @JAWS-test,

I think @detlevhfischer is tackling this, but in short:

• The enlargement is to make it 44 CSS px, so zoom does not count towards that.
• It is generally aimed at touch, although mouse users may benefit as well, if you click in the space between targets it doesn't automatically apply a heuristic to work out which link you meant to hit.
• I assume it would apply to browser-default components, but it's an interesting point.

[patrickhlauke]

noting that from an actual practical/user point of view - assuming zoom is not suppressed - using browser zoom will make things physically larger for users making targets bigger - but that it's really more a last resort for users having to enlarge all content just to be able to comfortably operate a control (and otherwise, if browser zoom was an acceptable solution, it would essentially make target size and target spacing SCs irrelevant/always passable unless zoom was prevented or capped)

[JAWS-test]

What happens if elements overlap each other, e.g. a pop-up, a submenu, a context menu, autocomplete list entries or an open selection list is located before links in the page. Do the pop-up elements, menu or list items then also need to have sufficient distance from the links? It should be noted that in many cases the links can also be activated if they are partially hidden by the above mentioned elements. Only rarely is it necessary to close the hiding element first in order to activate the links below it

The requirement holds for all interactive elements that do not fall under the inline exception (including native elements like selects, buttons or inputs of type radio or checkbox).

I didn't mean the distance between select elements, but the distance between option elements within select. In Chrome these are 19 px high and have no spacing. So they would violate this. The same applies to all other browsers. Would the new SC really invalidate all select lists?

The requirement holds independently of the zoom factor of the page. This means that authors cannot meet it by claiming that the target will have enough spacing or sufficient size if the user zooms into the page

But what if the web developer does not rely on the browser zoom, but implements his own zoom function to meet the exception "Enlarge: A mechanism is available to change the CSS pixel size of all targets so that the width and height are each at least 44 CSS pixels"? The effect would be the same as with the browser zoom, but it would satisfy SC, right?

While the Success Criterion primarily helps touch users by ensuring that activation with the 'fat finger' will not accidentally trigger adjacent targets, it is also useful for mouse or pen users

That something is useful does not answer the question whether the new SC can only be violated on mobile devices, or even if I have a WCAG test where mobile devices are explicitly excluded from the test

[patrickhlauke]

the SC isn't meant to be explicitly about touch, but the current wording is still riddled with talk of touch. it applies, just like target size SC, to all possible pointer interactions.

[patrickhlauke]

as pedantic as it is, there are still many instances of "criteria" (plural) where it should be "criterion" (singular). started commenting on them individually, but for brevity, just worth doing a quick once-over.

[detlevhfischer]

@JAWS-test

What happens if elements overlap each other, e.g. a pop-up, a submenu, a context menu, autocomplete list entries or an open selection list is located before links in the page. Do the pop-up elements, menu or list items then also need to have sufficient distance from the links?

I think the SC should certainly apply to targets in additional layers, including targets below that are possibly overlapped, but that that target spacing of elements on the page below should be assessed in the "default state", i.e., without any dynamic content opened on top of that default state. Not quite sure how to make this clear, and whether it is enough to add this to the understanding text and leave the SC text unchanged.

I didn't mean the distance between select elements, but the distance between option elements within select. In Chrome these are 19 px high and have no spacing. So they would violate this. The same applies to all other browsers. Would the new SC really invalidate all select lists?

Good point. I think it makes sense to add an exception for targets inside unstyled native elements (e.g., lists of select options). I would assume once the author changes these, the target spacing requirement would apply. I have changed the understanding text to include that exception.

But what if the web developer does not rely on the browser zoom, but implements his own zoom function to meet the exception "Enlarge: A mechanism is available to change the CSS pixel size of all targets so that the width and height are each at least 44 CSS pixels"? The effect would be the same as with the browser zoom, but it would satisfy SC, right?

Yes, IMO.

[detlevhfischer]

I note that the exception

Enlarge: A mechanism is available to change the CSS pixel size of all targets so that the width and height are each at least 44 CSS pixels;

is really too specific: it could also be enough to change the spacing without increasing the target size, or change both, so we need something like

Enlarge: A mechanism is available to change the CSS pixel size of targets and/or spacing between targets so that the width and height of both target dimension and spacing combined are each at least 44 CSS pixels;

[alastc]

Thanks for all the updates Detlev.

I'm a little concerned by adding an exception to the understanding document, I think we need to make that explicit in the SC text if we do, e.g:

User agent: The size of the target is controlled by the user agent and is not modified by the author.

Does that do the job? If so, we'll put back to the group.

[detlevhfischer]

Hi Alastair, Yes, i think that would do. Best, Detlev Sent from phone

…

Am 02.07.2020 um 23:33 schrieb Alastair Campbell ***@***.***>:  Thanks for all the updates Detlev. I'm a little concerned by adding an exception to the understanding document, I think we need to make that explicit in the SC text if we do, e.g: User agent:The size of the element is controlled by the user agent and is not modified by the author. Does that do the job? If so, we'll put back to the group. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[alastc]

Just noting that this PR was discussed today and no issues were raised with the changes. This will go out for CFC shortly.