Understanding 2.5.8 Target Size (Minimum) - 2 errors and request for spelling out telescoping spacing requirement

[patrickhlauke]

In https://w3c.github.io/wcag/understanding/target-size-minimum.html, second paragraph of the intent

For example, a target of 20 x 20px would meet the requirement if it had a spacing of 2 px on all sides

Shouldn't the spacing be 4 px? if it's measured from the farthest edge of the target to the nearest edge of the adjacent target, it'd be 20px + 2px = 22px, no?

In Figure 5, shouldn't the middle example be a fail rather than a pass? measuring from the top edge of the magnifying icon button to the bottom of the icon (which is where the underlying image/adjacent target "butts up" against the edge of the magnifying icon) it's 20px, so below 24px.

Lastly, one aspect that doesn't seem to be explicitly mentioned, but is quite crucial if you run the numbers/logic:

• if a target is 24x24, it can have targets butt up against it.
• if a target is smaller than 24x24, it then needs spacing around it - and crucially, the smaller the spacing, the larger the "exclusion area" becomes (see the below diagram where for a 24x24 target, you can have things directly around it...but for a 1x1 target, you need 23px clearance on each side, meaning the whole exclusive area becomes 47x47 centered around the 1x1 target)

[patrickhlauke]

To clarify on that Figure 5 thing ... the way I'd interpret it, the closest adjacent edge of the large target/image is effectively butted up against the bottom edge of the icon/button, so doing the "furthest away point to the closest adjacent edge" type calculation, it comes to 20px, so a fail?

[alastc]

Shouldn't the spacing be 4 px? if it's measured from the farthest edge of the target to the nearest edge of the adjacent target, it'd be 20px + 2px = 22px, no?

Yes, I think that's a leftover of the previous wording. I'm not in a super hurry to update that until the SC text is CFCed and settled.

In Figure 5, shouldn't the middle example be a fail rather than a pass?

That's why we need the "includes spacing" in the Spacing exception: "The offset between adjacent targets is at least 24 CSS pixels, where the offset is measured from the farthest point of one target to the nearest point of each adjacent target including spacing;"

I grant that this example is now less clear with the newer wording, but if you include the spacing around the small target, that meets the requirement. Again, happy to update the doc once we've CFCed the SC text.

Lastly, one aspect that doesn't seem to be explicitly mentioned, but is quite crucial if you run the numbers/logic:

Agree, but was there a question in that? If you're suggesting we include that as an example, I don't think we should, it is not something we are recommending.

[patrickhlauke]

That's why we need the "includes spacing" in the Spacing exception: "The offset between adjacent targets is at least 24 CSS pixels, where the offset is measured from the farthest point of one target to the nearest point of each adjacent target including spacing;"

So are you saying that middle of Figure 5 is a pass? do you mean the "farthest point" does count the spacing as well? I thought based on what @wilcofiers said in the thread in email, as a reply to my "can't we just say that there's a 24x24 area that's exclusively only containing that control", that this was not the case "We explored this. If you have two 5x5 buttons sitting right up against each other, with a bunch of space around them, they'll both pass because each can have the necessary space on opposite sides. The trick is for small things to measure the space between them, not the space around them. You can only do that from the farthest point of one, to the closest point of the other."

So just to be clear: is the Figure 5 example wrong? Or my understanding of what the "farthest point" is?

Agree, but was there a question in that? If you're suggesting we include that as an example, I don't think we should, it is not something we are recommending.

I think NOT pointing this out would be a huge disservice to readers. If you're aknowledging that this is indeed true, it is an important fact to note. It would even strengthen to some extent the rationale for this whole weird calculation stuff, because it points out that "we're trying to make sure that users don't press the wrong thing. the smaller the target, the more clearance it needs to avoid them pressing the wrong thing". why are you so afraid to point this out? it almost feels like you want to shy away from making this part any clearer because really you wish authors not to explore this avenue and just go with 24x24 ... which is laudable, but feels like you're purposely trying to social engineer them into your preferred solution that you're not able to make normative, so try to sweep details of the exception under the carpet?

[patrickhlauke]

not in a super hurry to update that until the SC text is CFCed and settled

I would suggest that as people are trying to work out if the normative SC text is appropriate/fit for purpose, it's also important for them to have a correct understanding to refer back to to check if it actually matches their expectation / to try to understand the implications of the normative wording...

[patrickhlauke]

So are you saying that middle of Figure 5 is a pass? do you mean the "farthest point" does count the spacing as well? I thought based on what @WilcoFiers said in the thread in email, as a reply to my "can't we just say that there's a 24x24 area that's exclusively only containing that control", that this was not the case "We explored this. If you have two 5x5 buttons sitting right up against each other, with a bunch of space around them, they'll both pass because each can have the necessary space on opposite sides. The trick is for small things to measure the space between them, not the space around them. You can only do that from the farthest point of one, to the closest point of the other."

sorry to harp on on this, but i'm trying to understand this aspect now (as it seems there's different interpretations now of what the spacing exception actually does/accounts for). is the middle of Figure 5 a Pass? based on what @WilcoFiers said, it should be a Fail, no?

a similar example...to super-small targets, butting up against each other, but with plenty of space all around them. do they Pass or Fail? if, as @alastc seems to suggest, we do count the spacing when considering the "farthest point", then they'd pass. otherwise, as per @WilcoFiers' and my interpretation, they fail. so which is it? this determines whether the spacing exception is clearly worded/makes sense, so this affects the normative wording...

Is this a pass or fail?

And, if this is a pass, then wouldn't my simplification of "it must be possible to draw a 24x24 box (or even a circle with 24px diameter?) that contains the target and nothing else - an exclusive area where there's only that target and nothing else" apply, contrary to what @WilcoFiers said about "The trick is for small things to measure the space between them, not the space around them"?

[JAWS-test]

Understanding says:

Providing spacing between targets will reduce the likelihood of accidentally activating the wrong control.

@patrickhlauke In your last example, there is no space between the targets, only enough space around the two targets. However, it is not possible to activate one target without accidentally activating the other. Thus, in my opinion, this would be a fail. If the current wording of the SC does not exclude this case, then it should be changed.

However, I think the current wording of the SC considers this very example a fail because it says:

The offset between adjacent targets is at least 24 CSS pixels, where the offset is measured from the farthest point of one target to the nearest point of each adjacent target including spacing

In your example the spacing is 5 px instead of 24 px

---

With the new wording of 2.5.8, however, the following sentence and the examples all no longer make sense in Understanding:

Where targets are embedded inside other targets, the inner target either needs a size of at least 44 x 44 CSS pixels or must be placed at the edge or corner to make sure that there is sufficient adjacent spacing in each dimension.

[detlevhfischer]

What about the following changes to the normative text:

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

• so getting rid of the 'including spacing' at the end of the spacing exception
• image 2 of fig. 5 would now indeed fail
• The exception for embedded targets (the current draft text still erroneously has 44 x 44 px) should then no longer be necessary.

With this wording, teeny weeny targets close together passing just by having enough space on opposite sides are then a thing of the past.

I also wonder why fig 5 has not been updated with the more recent graphic below that I had produced that showed 24 x 24px (maybe it got lost in our PR quagmire):

OLD (no longer correct):

But this needs to be revised now anyway, see below:

NEW (updated to new wording of spacing exception).

Would this work?

The understanding, to be sure, needs to better explain the spacing exception, for example by explaining that overlapping targets also count as adjacent. By getting rid of 'including spacing' and therefore measuring from edge to edge, it should be simpler (and easier to understand).

The bit

For example, a target of 20 x 20px would meet the requirement if it had a spacing of 2 px on all sides.

then also needs to change, as @patrickhlauke has correctly pointed out, to something like "a target of 20 x 20px would meet the requirement if it had a spacing of 4 px to any adjacent targets".

Still not sure whether there are still loopholes remaining for embedded targets - @WilcoFiers ?

We still need examples to clarify what counts as falling under the inline exception (see my examples here http://3needs.org/en/testing/code/pointer-target.html )

If there is agreement that this is the best way forward, I can work on the understanding text. Please provide feedback.

[alastc]

I think we've lost a little something, in that originally the middle option of figure 5 was intended to pass. When it was on the edge of the larger target you should have the positive effect of the spacing around it. I.e. you can aim for the top-left of the small target and be confident in not hitting the larger target.

However, for the sake of an edge case I won't object to the simpler SC wording.

Unless anyone can't live with it, it would be great for Detlev to make those updates.

(And now most of the updates have been merged, we should be able to get the right figure 5 in!)

[alastc]

I think the updates to target size understanding recently have addressed the issues noted in this thread.

The aspect that hasn't been added is the diagram showing a 1px target with spacing around it. I'm not keen on added that as it would appear to actively encourage that approach. Figure 1 makes the same point in a more subtle way.

[patrickhlauke]

The aspect that hasn't been added is the diagram showing a 1px target with spacing around it. I'm not keen on added that as it would appear to actively encourage that approach. Figure 1 makes the same point in a more subtle way.

I've opened a separate issue for this here the other day https://github.com/w3c/wcag/issues/1848

The "would appear to encourage" aspect can be counteracted by strongly worded prose that explains this is not a good idea, but it would admit to the reality of the SC (rather than taking a "if we keep this quiet, nobody will notice" approach).

[patrickhlauke]

I think the updates to target size understanding recently have addressed the issues noted in this thread.

indeed (modulo the above about spelling out the extreme 1x1 scenario). this issue can be closed.