SC 2.5.8 Pointer Target Spacing - Clarification: Overlapping Spacing

[bruskowski]

If I read this WCAG 2.2 WD success criterion (https://www.w3.org/TR/WCAG22/#pointer-target-spacing) correctly, the spacing around pointer targets is allowed to overlap, is that right? I am thinking of sidebars and flyout/dropdown menus here, maybe worth to add as an example as well.

An unintentional side effect might be that smaller pointer targets are incentivised, when people try to achieve narrow/compact rows.

x

[aardrian]

I think the Understanding doc addresses that:

If two or more touch targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same page.

Emphasis mine.

[bruskowski]

Yeah, I've read that too, but with target being defined as…

region of the display that will accept a pointer action, such as the interactive area of a user interface component

https://www.w3.org/TR/WCAG22/#dfn-target

… I'd assume that non-interactive spacing around that target (~margin) is not affected by this note. Thanks anyways!

[aardrian]

Ah. Gotcha. As you were.

[ajanec01]

@richardbruskowski

I think that your interpretation is correct. The first line is also pointing to it by saying that only the target areas can not overlap:

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets...

It does provide an incentive for smaller target sizes. The question I have, would a UX designer actually want to have such small targets? I mean, it seems obvious just by looking at it that it's not a good experience.

Also, although not desirable, the user can zoom in or use a browser extension to change the size of those elements. In fact, if the browser extension with a bit of css would make the targets overlap then I would consider that a failure. Maybe worth adding this to the understanding doc.

Those methods are not great but may work. Another possible solution would be to add a minimum requirement for the target area as per #1311

[bruskowski]

I agree @ajanec01 that such small target sizes hopefully won't be considered in reality. Here are some more realistic examples:

One reason I am interested in clarifying this: I assume having gaps between menu items that are not responding to the mouse (hover as well as click) is not ideal for a mouse users' experience: It's not how native/operating system level menus behave as far as I am aware. On the other hand pushing for (context-, navigation-, select-) menus with an item height of 44px might be challenging at times, at least in applications or websites with a somewhat high information density.

[ajanec01]

Yeah, I don't think it's desirable to have gaps, but I see it as a first step to make sure that users with dexterity impairments do not accidentally activate the adjacent component. Sc 2.5.5 pushes for the menus you mentioned to have the height of 44px but it is level AAA.
I actually see those two workings nicely with each other, unless, I'm missing out on something...

[aardrian]

I actually see those two workings nicely with each other, unless, I'm missing out on something...

That touches on another point, that this SC does not reference 2.5.5 at all. But I am bundling that up with other feedback.

[bruskowski]

One more example for further clarification. The way I read the SC the following would be true:

An element with a target height of 40px would fail if it sits next to another target, giving it an effective height of 40px.
An element with a smaller target height of 36px and 4px of space between itself and the next target would succeed, it would also have an effective height of 40px.

[ajanec01]

The way I interpret 2.5.8 is that both of your examples are a fail, not because of their target area (40 px) but because there is not enough space between the elements. This criterion is actually, mainly about spacing out your ui layout. Kind of like making a grid where each grid cell is at least 44px by 44px . You would need to make sure that each component has its own cell but how you position that component within the cell, i.e. bottom right, bottom left, etc., is irrelevant.

• In your first example, the element fails because it has the height of 40px and there is no space between the two adjacent elements that would make up for the 44px spacing.
• In your second example, it works pretty much the same. The total area between the elements (interactive and non-interactive) is only 40px and not 44px. If you added 2px of the non-interactive area to each side then that would be a pass.

[ajanec01]

Actually, now that I think about it, the first sentence indicates that the gaps can not overlap.

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets, except when:

It is not mentioned explicitly but it says what I mentioned about the grid cells so kind of excludes the overlapping of gaps. Sorry, got it wrong earlier on. It is worth highlighting it in the understanding doc.

[bruskowski]

@ajanec01 The sentence you've quoted, that is what I've tried to visualize with that little rectangle on the left side of each stack. In my last example, when that little rectangle is green, there this criterion is met in my understanding, because even if the spacing around the targets does overlap, there is still an area with a width and height of at least 44 CSS pixels that includes only that one and no other targets. It does include the spacing around another target, but not the target itself.

[ajanec01]

Sorry, didn't pay enough attention to illustrations- you're right @richardbruskowski! It should be addressed.

[mraccess77]

It is my understanding that inactive spaces could overlap as these inactive spaces are not part of the target area.

[detlevhfischer]

The intention was that inactive spaces should not overlap, that for the sake of measurement, you treat each target container as having a minimum height and width of 44 x 44. I guess we need to address that possible misunderstanding in the understanding document.

[mraccess77]

I think the group needs to weigh in on the overlapping inactive spaces as that was not my understanding.

[alastc]

My interpretation of this:

For each target, there is an area with a width and height of at least 44 CSS pixels that includes it, and no other targets.

Is that Richard's last set of examples was correct. I.e. the spacing can count towards more than one target.

• "For each target": we evaluate each target separately;
• "that includes it, and no other targets": If it doesn't include the other target it is fine.

I was also under the impression that was intentional, because having that spacing helps to differentiate taps, even if it is shared spacing.

[scha14]

Proposed response

SC 2.5.8 is intended to avoid accidentally activating targets if they are spaced too close together.

That is why, as a next level SC 2.5.5 is there to make sure the targets are large enough to be confidently activated.

[alastc]

Hi everyone, the mobile TF proposed an update which I added to this comment on 1384.

It would help to keep discussion of that in one place, so I'm just cross-linking...

[scha14]

Draft proposal based on latest discussion:

The offset between targets is at least 24 CSS pixels, where the offset is measured from the farthest point of one target to the nearest point of an adjacent target, except if:

1. Inline: The target is in a sentence or block of text;
2. User Agent Control: The size or spacing of targets is determined by the user agent and is not modified by the author;
3. Nested: Where one target is entirely enclosed within another target, each provides a unique target area of at least 24 by 24 CSS pixels;
4. Essential: A particular presentation of the target is essential to the information being conveyed.

Note: This criterion is about how targets are arranged on screen, not how the code is nested.

Related changes to the understanding document:

The requirement is for targets that are smaller than 44 x 44px to be included in an area with a width and height of at least 44px each. For the horizontal dimension, this means that the total width of 44px is composed of the width of the target and the width of the spacing that separates it from adjacent targets. The same applies to the height. For example, a target of 24 x 24px would meet the requirement if it had a spacing of 10 px on all sides. If the target is 44 x 44px or larger, no spacing between it and adjacent targets would be required.

The requirement is for targets to have at least 24 px offset between them. The offset between targets is the size plus spacing of a target, measured from the nearest point of each adjacent target to the farthest point of the current target. For example, a target of 20 x 20px would meet the requirement if it had a spacing of 2 px on all sides. If the target is 24 x 24px or larger, no spacing between it and adjacent targets would be required.

There are three exceptions:
If there is a mechanism to change the target sizes or spacing to meet the minimum, such as a button to change the sizes and layout of the targets.
If the target is inline within a sentence there doesn’t need to be a minimum target size.
If the spacing of the targets is essential to the information being conveyed there doesn’t need to be a minimum target size.

There are four exceptions:

• If the target is inline within a sentence there doesn’t need to be a minimum target size.
• If the size or spacing of targets is determined by the user agent and is not modified by the author.
• If one target is entirely enclosed within another target, each target needs to provide a unique target area of at least 24 by 24 CSS pixels.
• If the spacing of the targets is essential to the information being conveyed there doesn’t need to be a minimum target size.

...
...
Benefits
Having targets with sufficient target size spacing can help all users who may have difficulty in confidently targeting or operating small controls. Users who benefit include, but are not limited to:

...
...
Examples
Three buttons are on-screen and the target area of each button is 44 by 44 CSS pixels. Since the target size itself is 44 x 44 px, no additional spacing is required, the Success Criterion passes.
A row of buttons, each of which has a horizontal width of more than 44 px, but a height of only 30 px. Since there is sufficient spacing above and below the row of buttons, the Success Criterion passes.
Links within a paragraph of text have varying target dimensions. Links within paragraphs of text do not need to meet the 44 by 44 CSS pixels requirements, so the Success Criterion passes.

• Three buttons are on-screen and the target area of each button is 24 by 24 CSS pixels. Since the target size itself is 24 x 24 px, no additional spacing is required, the Success Criterion passes.
• A row of buttons, each of which has a horizontal width of more than 24 px, but a height of only 20 px. Since there is sufficient spacing above and below the row of buttons, the Success Criterion passes.
• Links within a paragraph of text have varying target dimensions. Links within paragraphs of text do not need to meet the 24 CSS pixels requirements, so the Success Criterion passes.

[bruskowski]

That answers the question I had. Thank you for sharing!

[alastc]

Thanks @richardbruskowski, as you consider that answered I'll close this issue.