Target spacing (minimum): multiple overlapping elements interact oddly with offset

[WilcoFiers]

In working on automated tests, I ran into something I hadn't realised before. When an element is overlapped by multiple other elements, it is possible to pass the SC with a very small target on the outer element. In particular scenario H4 from my codepen:

https://codepen.io/wilcofiers/pen/abZxPow?editors=1100

H4 shows a rectangle with two squares on top of it. The squares touching edges horizontally. The squares have a 24x24 diameter and so pass. The rectangle is only visible as a 6 pixel wide perimeter around the two squares.

The reason this passes is because to the offset from the rectangle to either square is a diagonal from their top-right corners for the left square, or their top-left corners for the right square. For both squares the offset is slightly more than 30 pixels, so the rectangle meets the offset exception. The odd thing here is if those two squares were treated as a single target, the SC would fail. But because there are two of them, the SC passes.

I have no suggestion on how to fix this, without causing a good deal of other problems that might get overlooked. Given how unusual this case is, I think it's acceptable to ignore it. But I did want to point it out so we're conscious of it.

[patrickhlauke]

The reason this passes is because to the offset from the rectangle to either square is a diagonal from their top-right corners for the left square, or their top-left corners for the right square. For both squares the offset is slightly more than 30 pixels, so the rectangle meets the offset exception.

not quite sure i follow. are you selectively choosing the furthest square away from each corner of the rectangle? i don't think that tracks with the SC wording of "at least 24 CSS pixels to every adjacent target" (emphasis mine on the last three words)

[patrickhlauke]

(related, this also opens up something I pondered previously...that our general discussion, even in the understanding document, when it comes to spacing is to look at just horizontal and vertical distances between flat faces, rather than diagonals - which makes me wonder if we do need some examples relating to diagonals. and probably some examples involving complex non-rectangular shapes altogether, which can and will crop up once you try to apply the SC to things like interactive SVGs, and even regular HTML controls with clipping paths)

[bruce-usab]

@patrickhlauke – I understand every adjacent target to be anywhere on the target – so I think @WilcoFiers may have flagged an important defect here. I am not sure it is that unusual a situation either, except I cannot think of a real life example with buttons on top of buttons.

I agree we should probably limit the measurements to horizontal and vertical distances.

@WilcoFiers is "squares have a 24x24 diameter" a typo or does it reflect difference between British and U.S. English? Regardless, I presume you mean diagonal or side, but I do not know which!

[patrickhlauke]

I understand every adjacent target to be anywhere on the target

sure, but you basically have to check the spacing/distance to every one, and if for any of them falls below 24px, then it fails that clause, no? (i.e. "I'm 10 feet away from every person in this room" means that i can't just pick the one i'm furthest away from and say i satisfy that statement, while there's somebody literally pressed up against me - i need to check my distance against every other person in the room, and if one of them is closer than 10 feet, i'm lying)

[alastc]

I also don't understand why that would pass, offset is defined as "the distance measured from the farthest point of a target to the nearest point of the second target".

The target-offset for the large item is 6px, maybe slightly more if you take the diagonal from the top-right corner of the large target to the closest point of the nested target. For the nested targets it is the size of the target.

The spacing exception is "to every adjacent target", so you have to calculate for each, not any.

[JAWS-test]

In Wilco's figure, it applies that the target offset between all objects is greater than 24 because the objects are greater than 24. Thus, Wilco has actually found a loophole of the criterion.

We have the note:

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.

Better would be: If two objects overlap completely, the target size of both objects must be at least 24x24 px

[patrickhlauke]

sorry @JAWS-test but i think you've got the wrong end of the stick here...nothing to do with the inner targets being 24x24 or greater, this is about determining if the outer target passes the SC

@wilco, it might help if you drew some diagrams/lines here to clarify what you're actually looking at in terms of diagonals, and what makes you say the current wording allows for this to pass (for the outer control)

[mraccess77]

Hi agree with @patrickhlauke as the outer is too close to the inner targets and that you have to test each.

[patrickhlauke]

one potential weirdness/gap i can see though is that as originally worded, there's is not really a good provision for targets that are contained inside each other but offset - even looking at examples H1/H2 you have to decide to measure from the right edge of the rectangle to the right edge of the single square to say it passes, because if you looked at the left edge of the rectange to the left edge of the square it would fail ... basically you're trying to determine if there's at least some area of at least 24x24 pixels on the big rectangle that's clear/unobstructed by the square. so it's this aspect that is a bit fudged with the current wording [edit: i mean you can handwave it by saying that the large target, even minus the smaller inside target, still has a size that's greater than 24x24 so it passes even before you hit the exceptions, but it's not made explicit]. it could also come about again with overlapping or complex shapes.

[alastc]

Agree with Patrick, going from:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels (no), except where the distance measured from the farthest point of a target to the nearest point of the second target is at least 24 CSS pixels to every adjacent target;

For the outer target, these are the two things I'd look at for the inner images: (alt = original H4 with two short red lines going from the outer edge of the outer target, to the outside of each inner target.)

[JAWS-test]

target offset: the distance measured from the farthest point of a target to the nearest point of the second target

@alastc: You have not connected the farthest point, but the two nearest points.

If I take the farthest point, I always get (no matter if I start from the outer or inner rectangle) 24 px + x px and thus the SC is fulfilled

[alastc]

OK, I think I get it, you mean like this? (alt = original H4 with two longer red lines going from the outer edge of the outer target, to the outside of each inner target, but overlapping the second inner target.)

[JAWS-test]

Related to the left inner square:

• white arrow: farthest point of inner target to nearest point of outer target
• black arrow: farthest point of outer target to nearest point of inner target

The question is: if there were only the left inner square: would that be valid. According to Figure 5 in Understanding, yes. Now the right square is added, which also has sufficient distance to the left and outer square - the trick is only that the remaining click area of the outer square is now too small, because it is hidden. But the current wording of the SC does not forbid this.

[alastc]

@JAWS-test that is testing the inner targets, how do you test the outer target?

I.e. the furthest point of the outer target, to the closest point of the inner target.

Also, in testing the inner targets, it would end as soon as it hit the outer target, i.e. the width of the inner target.

[JAWS-test]

@alastc I did not look at the two inner ones at all, but only the left inner one to the outer one

[alastc]

@JAWS-test This is a for-each situtation, i.e. you test each target compared to its adjacent targets.

If you take the outer one and test to each inner one, your white arrow is not valid because it starts in the inner one. The black arrow should also stop as soon as it hits a inner target.

I can see confusion in that there is overlap with a 3rd target, but given the inner target is not part of the outer target, I think the arrow would have to stop when it is not part of the outer target or spacing.

[JAWS-test]

• 1st figure: Inner rectangle (24x24 px) and outer rectangle (much larger): I measure farthest point to nearest point, once from inner to outer (left arrow), once from outer to inner (right arrow). Distance in each case 24 px + x = passed
• 2nd figure: 2 inner rectangles (24x24 px) and one outer rectangle (clearly larger and sufficient distance between both inner ones, i.e. more than 24 px): same measuring method. Distance in each case 24 px + x = passed
• 3rd figure: 2 inner rectangles (24x24 px) and outer rectangle (less than 24 px distance between the two inner ones): same measuring method. Distance 24 px + x each = passed

@alastc If I use your measurement method (nearest to nearest point instead of farthest to nearest point), already example 1 or at least example 2 would not pass - but why should they not pass?

[patrickhlauke]

@JAWS-test

In terms of checking if the rectangle itself passes/fails (you'll still need to run considerations for the square(s) separately of course)

1st figure: Inner rectangle (24x24 px) and outer rectangle (much larger)

you don't need to run any spacing measuring to check if the outer rectangle has sufficient distance because the rectangle itself, even once you ignore/take out the inner square, has an area that's >= 24x24

2nd figure: 2 inner rectangles (24x24 px) and one outer rectangle (clearly larger and sufficient distance between both inner ones, i.e. more than 24 px)

same, even if you cut out the two squares, the rectangle has an area >= 24x24

[JAWS-test]

@patrickhlauke

Figure 1+2: If I understand you correctly, you are saying that I don't need to measure any distance at all because all 3 objects are large enough (> 24x24 px). I see it that way too.

But let's come to the third figure (you don't write anything about this, but this is the crucial example):

• The two inner ones are ok, because 24x24 px
• The area of the outer one is clearly bigger than 24x24 px, minus the two inner ones the total area is bigger than 24x24 px, but there is no area inside the outer one which is big enough by itself (24 x 24 px). I.e. this example should violate the SC, even if the distance measurement according to the definition of "Target offset" says the opposite

[JAWS-test]

The note at target is also strange:

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.

This should only apply to the lower, hidden element, not the upper element. If this also applies to the upper element, then it would mean that its target size is 0.

[patrickhlauke]

you don't write anything about this, but this is the crucial example

well yes, that's the point of this thread (before you came in with https://github.com/w3c/wcag/issues/2159#issuecomment-988045587)

[WilcoFiers]

@alastc Yeah, I think your example is close, except don't forget there's a diagonal component to this. If the rectangle wasn't sticking out above and below the squares, this would be a little easier.

The offset between the rect and the left is measured like this:

1. The farthest point from the left square that is on the rectangle is the top-right, or bottom-right corner (doesn't matter which)
2. From the top-right corner of the rectangle, the closest point on the left square is its top-right corner
3. The distance between the top-right corner of the rectangle and the top-right corner of the left square is 30.6px.

The same is true for the right square, except its closest edge is the left edge. So the offset to both adjacent targets is 30.6px. Therefor the SC meets the spacing exception.

[JAWS-test]

@patrickhlauke

Why I measured the target offset despite the area of 24 x 24px, had the following reason:

• The SC only talks about the target offset and it is determined like this.
• The target offset is relevant in the example of Wilco
• Those who argued against Wilco measured the target offset wrong. To clarify this, I have created the 3 figures to show how it must be measured correctly (namely always in the same way and not suddenly differently)

[JAWS-test]

Wouldn't it be easier to say (for non-overlapping targets):

• Take the midpoint of the targets
• Draw a circle of 24 px around the midpoint
• There must be no other target in this circle

For overlapping targets:

• The inner one must be at least 24x24 px
• The outer target must also have a contiguous clickable area of at least 24x24 px

[JAWS-test]

the distance measured from the farthest point of a target to the nearest point of the second target

Unfortunately, I am not a mathematician to say whether this definition makes any sense at all with respect to irregularly shaped objects. Because, of course, I can always find the farthest point on an object with respect to an already defined point. But here I am supposed to determine the farthest point in relation to what: a point at the edge of the object, to the center of the object, to the nearest point of the object (which I don't know yet, but can only determine in the second step).

[WilcoFiers]

@JAWS-test We've worked on overlap in the past. Didn't quite work out. The thing is that you can create this exact same scenario without overlapping.

Again, I don't know if this is a thing we need to solve. This is such an odd scenario, and we currently have an SC that seems almost understandable. I'm reluctant to tweak it more just to handle this really unusual edge case.

If we did want a to solve this, I think the following SC would do it. It combines the spacing / size thing into one requirement again.

For each target, there is a circular area with a diameter of 24 CSS pixels that includes no other targets. The center of this area must be within the target. Exceptions apply for the following cases:

• Inline: The target is in a sentence or block of text;
• Necessary: A particular presentation of the target is essential or is legally required for the information being conveyed;

Perhaps 25px would be better, as that actually has a central pixel. I've tried to pitch something like this in the past. It didn't work then because I hadn't thought of the "center within the target" part. This feels more intuitive to me, as the way you'd interact with a touch screen. There's a point you're aiming for that's on the target, and then a click anywhere within 12 pixels of that point should not activate the wrong target.

[alastc]

The SC only talks about the target offset and it is determined like this.

@JAWS-test, are you going from the latest version? That is:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: The target offset is at least 24 CSS pixels to every adjacent target;

Therefore if the target itself has 24 by 24px (removing overlapping targets), it passes without needing the exception. So your 3rd example from above is the only one that would fall-back to trying the offset approach.

(alt= boxes from Jaws-test's example above, the first two examples showing each has sufficient area. The third example has a large box with two smaller nested boxes. There is insufficient area showing in the large box, but if you measure between the large box and one of the smaller ones, ignoring the other, then it could pass despite not having 24px of sizxe+spacing.)

Green fuzzy lines for 24px or over, pink solid line for failing distance.

My concern is that if you ignore the second nested target, then "A to B" passes.

The offset between the rect and the left is measured like this:

• The farthest point from the left square that is on the rectangle is the top-right, or bottom-right corner (doesn't matter which)

@WilcoFiers From the text, why do you assume you avoid the 3rd target? Working through these examples, it doesn't look like overlap with a 3rd target is considered. I.e. you could ignore the 3rd one and treat that as spacing.

My suggestion is to modify the top of the SC to prevent diagonal shenanigans:

The size of the target for pointer inputs is at least 24 CSS pixels horizontally by 24 CSS pixels vertically, except where:

Then in the target offset definition state that other targets are not included in the measure:

the distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target, it does not include other targets. The target offset from A to B may be different then the offset from B to A, if the size of these targets differ.

[patrickhlauke]

I was also a proponent of the idea of the circles of exclusion, centered on the targets, fairly early on. There were objections back then because that approach then failed certain cases. Think we've been around this same back-and-forth many times...

EDIT: from memory, the problem was that for certain shapes, it was not obvious how to even find the center. and that for some shapes, it's not so much the center itself that matters, but basically having some area somewhere that's a circle with a radius of 24px that is still at least one pixel "inside" the target, and then has no other targets there either (which would account for spacing as well). and it all just ended up being very messy (again because of the idea that spacing needed to be taken into account)

[alastc]

Yea, I seem to remember circles got messy, not least of which because we primarily (but not exclusively) work in rectangles, so it makes the obvious cases less obvious.

I'm certainly not set on messing with the SC text, we could except the odd diagonal case for nested targets.

However, the update to the target-offset might be worth doing?

[WilcoFiers]

The size of the target for pointer inputs is at least 24 CSS pixels horizontally by 24 CSS pixels vertically, except where:

I don't think that changes anything on this example. I don't know that WCAG needs to be this explicit, but if we wrote an ACT rule it would absolutely say something like that.

the distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target, it does not include other targets. The target offset from A to B may be different then the offset from B to A, if the size of these targets differ.

What does the word "include" mean in your addition. We're computing the distance between two points. How can a shape be included in a distance? One's the length of a line, the other is an area. Do you mean the line doesn't intersect the area or another target? That wouldn't exactly help this case since that second square doesn't intersect.

[alastc]

@WilcoFiers - If it is explicitly vertical and horizontal, that doesn't allow for diagonals. You'd have to find a vertical line of 24px, so your last example wouldn't pass (unless you ignore the other target). Hmm, I guess we'd have to apply that to the offset bullet as well.

Spacing: The target offset is at least 24 CSS pixels vertically and horizontally to every adjacent target;

Re "include", it says "not include", i.e. you can't treat it as part of target A or B, and you can't treat it as spacing. Otherwise, by the letter of the definition you could measure from the right-side of the outer target (A) to the nearest point of the left target (B), through another nested target (C).

[WilcoFiers]

@WilcoFiers - If it is explicitly vertical and horizontal, that doesn't allow for diagonals. You'd have to find a vertical line of 24px, so your last example wouldn't pass (unless you ignore the other target). Hmm, I guess we'd have to apply that to the offset bullet as well.

I think I see what you're trying to get at. I'm not sure I like that. That creates its own problems. If offset can't be a diagonal, then targets that are positioned diagonally don't have an offset anymore. We went down that road before. Didn't go well.

Additionally, if I need to determine if another target intersects my "offset line". I can't just measure at any arbitrary vertical position. If I change the top margin on one of the squares, I now have a case where depending on where along that edge I measure, I may or may not intersect with another target. We then need to explicitly define where to draw that line.

I don't think this solution would work. Personally, my vote is for accepting this as an unaddressed edge case.

---

Edit: Opened a new issue #2162

[JAWS-test]

@alastc In your comment the pink solid line stands for the failing distance - but this line fails because of common sense and not because of the definition of target offset

[alastc]

@JAWS-test We all agree the pink link fails (the SC's first line), but with the wording of target offset, I think the green lines pass the outer target due to the spacing bullet.

Those green lines for the outer target match "The distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target."

@WilcoFiers - agree we should leave the diagonals alone. What about tightening up the definition?

[mraccess77]

If you are measuring the horizontal for a rectangle I think you should only be measuring horizontally. If you are measuring vertically for a rectangle I think you should only measure vertically - so no diagonals. For other shapes like stars and such you may need to have measurements do not use horizontal or vertical lines.

[patrickhlauke]

Coming back to the idea of circles one more time (since they've been resurfaced here, and it's been bouncing around my mind since)... leaving aside that they potentially make the common case more difficult to grok (though not by much, seeing our general to-ing and fro-ing to understand the language in the SC here as it currently is), would this capture the essence of what we want? This now includes the idea of spacing which is where the "take the midpoint of the target" / "circles can't overlap" (which broke the spacing idea) seemed to fail at the time

For each target, it must be possible to draw a circle that:

• has a diameter of 24 CSS px
• contains at least a 1x1 CSS px of the target in question
• contains no pixels from any other adjacent target

I think this would, in essence, apply to all the general cases, as well as the edge cases of overlapping or completely wrapped/surrounded/nested targets alike. it should also work when targets have odd shapes (e.g. some kind of SVG puzzle with irregular interlocking shapes etc).

downside, of course, is that it more clearly reveals that "1x1 CSS px targets can be valid as long as there's enough spacing around them" fudge that we tried hard to hush up/make non-obvious

[JAWS-test]

@patrickhlauke I think your circle definition doesn't work because of the 2nd point: that allows two targets each 1x1 px, right next to each other. The important thing is that the circle is around the center of the target, so that there is enough space between the targets.

And: the midpoint is mathematically precisely defined (in contrast to the concept of target offset): https://en.wikipedia.org/wiki/Centroid

[patrickhlauke]

I think your circle definition doesn't work because of the 2nd point: that allows two targets each 1x1 px, right next to each other

ah yes, this was part of the square we couldn't circle (pun intended) at the time as well. it once again goes to show that this SC, with its "either sufficient dimensions, OR dimensions + clearance to adjacent targets" approach trying to do two things, causes issues...

the idea of the centroid is also irrelevant though, because it doesn't make a difference whether or not a user can tap/click on the centroid or not with sufficient clearance. it's just requiring that there be some place somewhere where the user can comfortably click/tap and that has sufficient target area or at least sufficient clearance. doesn't have to be at the centroid (thinking of irregular-shapes controls - which is in fact what we get with overlapping/nested targets as well)

[patrickhlauke]

the only other way out, if using the idea of circles, would then possibly be to add further clauses...

if the circle with diameter of 24px is not fully contained inside the target (i.e. the target is small), then the shortest distance between the target and any adjacent targets is at least "(24px minus the diameter of the largest circle that can be contained inside the target)" ...

which gets messy, but I think then captures the "two 1x1px targets next to each other" case as well

[alastc]

Having been through 2 wide reviews, we're at the go/no-go stage barring small tweaks. Switching to a circle method isn't a small tweak.

[patrickhlauke]

the fact that we're still, months later, finding the approach to be hard to understand, and bringing up weird edge cases (and we've not even looked at non-rectangular target areas in depth, which will become more common as clipping paths and interactive SVGs are being taken up) doesn't fill me with confidence on the "go" stage to be honest...

and to be clear, my fear is that any "ah well, it's good enough for the most part, we'll handwave the gaps/edge cases" now will only come back to bite us later on when more of those bubble up when this SC crashes against varied real-world content, and then it's too late to address other than spackling on more exceptions/clarifications/handwaves

[bruce-usab]

"multiple buttons overlaid on another button" does not seem like (much of) an edge case to me.

[alastc]

the fact that we're still, months later, finding the approach to be hard to understand, and bringing up weird edge cases...

The key for me is whether it would bring up false positives. I.e. could the SC catch reasonably large targets that we think should pass, but fails those examples.

If it misses a few edge-cases that we think should fail, but don't, that is the lesser problem. (You learn from that and add something later, as it stands probably in WCAG 3.) This is another example where the more it is defined to catch all possible cases, the less understandable it becomes (or it has to be more prescriptive).

In the meantime it could be catching the egregious cases and giving designers / developers a general sense that targets shouldn't be tiny.

Bruce wrote:

"multiple buttons overlaid on another button" does not seem like (much of) an edge case to me.

You might struggle to find a failing example, it's generally not great for usability either. The only example I can think of is a map with pins, and it would probably fit the 'essential' exception due to needing to display the pins at particular locations.

[JAWS-test]

@alastc

Spacing: The target offset is at least 24 CSS pixels vertically and horizontally to every adjacent target;

This would not be a good idea because then in my figure the two blue 2 x 2 px squares in a line would violate the SC, the same squares arranged diagonally (and in yellow) would fulfil the SC, although they would be closer together and thus more difficult to operate

[JAWS-test]

If we keep with target offset, I suggest to adjust the first exception as follows:

Spacing between non-overlapping targets: The target offset is at least 24 CSS pixels to every adjacent target.

Reason: For overlapping objects, target offsite does not work. I.e. the exception does not apply to them, so they must be 24 x 24 px in any case. This applies to the upper object, but also to the underlying object: an area of at least 24 x 24 px must also be uncovered.

Another example of why target offset does not work:

• large blue circle (100 px diameter).
• small yellow circle (2 px diameter, exactly in the middle of the blue circle)

target offset: 51 px, although the yellow circle is obviously too small

Or analogue

• large blue circle (100 px diameter)
• large yellow circle (98 px diameter, exactly in the middle of the blue circle)

target offset: 99 px, although the clickable area of the blue circle with 1px width is obviously too small

[JAWS-test]

I sought advice from a mathematician: For complex objects, determining target offset is not trivial. Imagine a map where each city should be clickable. What scale do I have to use so that the city boundaries of neighboring cities have enough distance from each other. Even for a circle and a triangle next to each other it is not so simple to determine the farthest and the nearest point (because first for each point on the circle the farthest point on the triangle has to be determined and then of all these distances the shortest has to be chosen - and then the other way around). For rectangles positioned at the same height and of the same height, target offset is extremely simple and effective - but as @patrickhlauke wrote:

some examples involving complex non-rectangular shapes altogether, which can and will crop up once you try to apply the SC to things like interactive SVGs, and even regular HTML controls with clipping paths)

However, I can live with the fact that the SC has various loopholes - the intention is clear and most targets on the web are rectangular and thus easy to test

[WilcoFiers]

@JAWS-test Maps that can resize are one of those exceptions where the target size is essential.

Your very large / very small circle example isn't correct. The large circle passes, but the smallest one fails. For the small circle, the farthest point away from the larger circle is right in the center. From there, the closest point to the larger circle is on the perimeter of the small circle. So the offset is the radius of the small circle.

I'll add an example to my codepen for that one. That's a good case to have an example of.

---

@patrickhlauke The biggest drawback to that circle solution is that it incentives smaller target. In the current SC, a button that's 6px wide needs 18px space to the next target. 12px space if the button is 12px, and 6px if the button is 18px. With the circle solution that first case, it's 12px space for a 6px button (the other two are the same). That's the reason we went for this one. It's an alternative, with its own drawbacks.

[patrickhlauke]

@WilcoFiers

The biggest drawback to that circle solution is that it incentives smaller target. In the current SC, a button that's 6px wide needs 18px space to the next target. 12px space if the button is 12px, and 6px if the button is 18px. With the circle solution that first case, it's 12px space for a 6px button (the other two are the same)

from my comment here https://github.com/w3c/wcag/issues/2159#issuecomment-988843465

if the circle with diameter of 24px is not fully contained inside the target (i.e. the target is small), then the shortest distance between the target and any adjacent targets is at least "(24px minus the diameter of the largest circle that can be contained inside the target)"

a 6px wide button would need 24px - 6px = 18px (not sure how you got to 12px?)

note that in my addendum i explicitly talk about "distance", not this concept of "offset" that munged both the diameter itself and the spacing together. talking just about distance at that point (when the target is too small to contain a circle with diameter 24) avoid the messy "opposite side / furthest away edge" kind of stuff

it still doesn't perfectly solve all situations, but i think this covers both the ones that the current wording addresses, plus the outliers mentioned in the OP

possibly simplified:

each target needs to be able to contain a circle with a diameter of 24px. if it doesn't, then:

• find the largest circle that does fit into the target
• if there are no adjacent targets, it passes
• if there are adjacent targets:
  • from the perimeter of this circle, find the shortest distance to all adjacent targets
  • for each adjacent target, the distance must be at least "24px - diameter of this largest circle" or it fails (this is, effectively, the idea of "offset", but now not direction to horizontal or vertical...it can be any arbitrary direction, including all diagonals)

[JAWS-test]

@WilcoFiers

Maps that can resize are one of those exceptions where the target size is essential

I am aware of that. However, there are many maps that cannot be enlarged, e.g. https://www.coronavirus.sachsen.de/infektionsfaelle-in-sachsen-4151.html

Your very large / very small circle example isn't correct. The large circle passes, but the smallest one fails. For the small circle, the farthest point away from the larger circle is right in the center. From there, the closest point to the larger circle is on the perimeter of the small circle. So the offset is the radius of the small circle.

This is where the problem starts, that it is unclear whether target offset refers to a point within the object or to a boundary point. I assumed a boundary point because this would be the case for non-overlapping objects. If it doesn't have to be a boundary point, I could also assume that target offset is always 0 for overlapping objects, since there is a point of the lower object under each point of the upper object. However you look at it, target offset doesn't work well for overlapping and irregularly shaped objects because of loopholes and imprecise definition.

[alastc]

For overlapping objects, target offsite does not work.

With the definition of target (~ the area available for pointer input), there is no such thing as an overlapping target. One of the targets will be on top (from a tech point of view) and be "the target", the other is not the target in that area of overlap. So overlap is ok, the examples above where it is trickier is due to diagonals or nesting.

it is unclear whether target offset refers to a point within the object or to a boundary point.

It refers to the nearest/furthest point, so would be on the boundary.

The main thing you seem to be missing is that you do it in a 'for each' manner. I.e. consider target A, and take furthest point of A (to B), and the nearest point of B to A. Then do the same for target B (to A). When you think about it like that the circle example resolves as Wilco said.

If you have a nested target, then the offset for the nested target is actually less than the size of the target, that exception doesn't help you pass. Being nested is the only case I can see where it wouldn't be measured from a boundary point, and it doesn't help you pass.

If a target A overlaps horizontally with target B and they are the same height, you just treat that overlap as belonging to whichever is on top, and measure the sizes.

If target A is less than 24px by 24px and overlaps horizontally with target B, and B is larger, I don't think the offset exception helps you pass (which is not a bad thing).

I can live with the fact that the SC has various loopholes - the intention is clear and most targets on the web are rectangular and thus easy to test

I think that's where most of us are. The likelihood is that switching to a different approach brings up a different set of odd cases, we did try the circles one before.

I don't think anyone commented on my suggestion to tighten up the target-offset definition to exclude other targets?

the distance measured from the farthest point of a target to the nearest point of the second target. Offset includes the target and spacing around the target, it does not include other targets. The target offset from A to B may be different then the offset from B to A, if the size of these targets differ.

That was to stop people ignoring target C when calculating the distance between A & B.