Spacing clause update

[alastc]

Closes #3050

[patrickhlauke]

as mentioned in the survey, this seems to be quite a fundamental change to something that's been laboured over for years...and will also require a whole change to the related understanding document / testing approaches / etc. suggest it's worth bundling all of that together in the same PR here, to make clear what the impact/change proposed here actually is in practice

[JAWS-test]

Targets are spaced such that if 24 CSS pixel diameter circles are centered on each target, none of the circles intersect another circle or target

Think the new spacing exception is much better than the previous one. But think that the "centered" should be removed because it excludes certain well clickable targets, like e.g.

• Circle with 20 px diameter and circular ring with thickness of 20 px and diameter of 100 px (see figure 1).
• Two bars (20 px wide and 100 px long) arranged as in a plus or x sign (see figure 2).

Figure 1:

Figure 2:

In both cases, a centered circle of the two targets would be identical because both objects have the same center, but the click area is perfectly adequate.

If desired, I can make corresponding illustrations for my two examples.

[mbgower]

I think this scans a bit better

Suggested change

	<li><strong>Spacing:</strong> Targets are spaced such that if 24 CSS pixel diameter circles are centered on each target, none of the circles intersect another circle or target.</li>
	<li><strong>Spacing:</strong> Targets are spaced such that if a 24 CSS pixel diameter circle is centered on each target, none of the circles intersect another circle or target.</li>

[mbgower]

I also think that we can make a small addition to take care of an edge case. I have combined the prior suggestion with this one here.

Suggested change

	<li><strong>Spacing:</strong> Targets are spaced such that if 24 CSS pixel diameter circles are centered on each target, none of the circles intersect another circle or target.</li>
	<li><strong>Spacing:</strong> Targets are spaced such that if a 24 CSS pixel diameter circle is centered on each undersized target, none of the circles intersect another circle or target.</li>

[JAWS-test]

@mbgower Which edge case should make it necessary to insert "undersized"? My examples are not.

[alastc]

@JAWS-test in the case of a large target with small target inside (with some spacing) in the centre, their circles will overlap. Assuming the large target passes the primary line of the SC, we don't need to worry that it's circle overlaps the smaller target's circle.

[JAWS-test]

@alastc My examples were such that both targets are not large enough (see above)

[mbgower]

@JAWS-test For the tiny circle inside a big thin donut example, I can see a way to word this to cover this edge case, but it would begin to get pretty cumbersome ('centered within' or something like that that makes it clear that the center point has to actually be part of the target). As far as I can tell, the only odd scenario left with this wording is the one you mentioned -- a small target centered inside another small target with sufficient spacing such that risk of hitting the wrong one isn't increased. But I personally have no issue telling the owner of such a designer that they should just make their targets big enough. It seems like an obscure pattern, where users could be understandably confused that there are actually 2 different targets (sorta a radio button where the outside border and inside circle are separate targets!).
The new wording makes common patterns easier to assess (with understandable outcomes).

[JAWS-test]

@mbgower I have added the two figures above. The question is why the circle must be centered? In the example with the "radio button" (inner circle, circular ring) the strange thing is that it forbids the variant with the best click area (figure 1), but allows if the inner circle is moved closer to the circular ring (see figure 3), although this is harder to click

Figure 3:

[mbgower]

@JAWS-test

The question is why the circle must be centered?

We've already gone into that exploration before. If you remove the centered notion, you immediately end up with odd allowed edge cases too, not to mention the whole thing is a lot more fiddly to test.
As stated in other threads, it's really useful to look at these things at scale. I encourage you to draw these things at scale and ask yourself whether any of those are good designs.

[JAWS-test]

@mbgower

ask yourself whether any of those are good designs

I don't think that's the question, at least not for me as a WCAG tester. As a WCAG tester, I wonder much more why example 1 fails and example 3 passes, even though 1 is better than 3.

[mbgower]

wonder much more why example 1 fails and example 3 passes, even though 1 is better than 3.

I think a better way to look at this is to phrase that as "even though 3 is an even worse design than 1". They are both pretty bad.

It is possible to come up with hypothetical edge cases that demonstrate shortcomings of pretty much every requirement. Whether anyone would be well-served by someone implementing such a design is a valid question, IMO. Do we create SCs that seek to guide real-world design to a better outcome, or do we focus on preventing a bunch of unlikely edge cases by creating a wordy SC that is not easy to understand or implement? My firm belief is we should not allow the perfect to be the enemy of the good.

BTW, the metrics are such that for the uncentered circle in the ring to pass, it has to be big enough that the circle is about 20 pixels in diameter. It's nothing to celebrate, but since it's the same spacing needed for an undersized circle target close to a full-sized target, it is at least consistent, from that perspective. This is approximately to scale.

[patrickhlauke]

It's a side conversation, but I'd still be interested to know what has changed now that makes us explore the idea of circles, when that same idea was shot down years ago when I floated it (see my mention here, but I'm certain I had that discussion about circles even well before then: https://lists.w3.org/Archives/Public/w3c-wai-gl/2021JanMar/0132.html) for having gaps/problems.

Speaking of the understanding document that will also need to be updated for this fundamental change: if somebody can provide me just with a rough sketch, I can work on getting some clean SVGs done in the same style as #3058 (which I assume will now be obsolete work, which is a shame since it took me forever to get those just right and accurate)

[mbgower]

@patrickhlauke, you said:

I'd still be interested to know what has changed now that makes us explore the idea of circles, when that same idea was shot down years ago when I floated it

I see this in the archive you cited:

each target "has an area of 24 x 24 pixels which includes the target, and any spacing, that does
not contain any other adjacent target" or similar. That there's
essentially an "area of exclusion" / "exclusive area" of 24 x 24 pixels
that only contains that particular target. This would be much more
straightforward to understand (and effectively, I'd hazard a guess that
that's how auditors will test it as well ... they'll have a 24 x 24 CSS
px overlay and they'll check if that can be placed on a target and have
no other adjacent targets intruding in it.

So, first, do you agree that what we're proposing here is closer to that vision? We get to toss out the whole cumbersome definition of offset, for one thing.

To me, what has changed is that the language of the SC got firmed up, we got some fresh people contributing, and we came up with a way to word things that seemed clearer and without apparent issues on the use cases provided to date (the circle is centered on an undersized control). I think an acknowledgment that every approach to date resulted in odd edge cases also made it clearer that we need to think about the common, and have clearer guidance on that. It's also possible that whoever didn't like the circle assessment last time, won't this time either.

I hope you'll agree that with a few illustrations, this new wording should be much easier to convey to users, while not actually changing the basic goal you were intoning in that old list.

[patrickhlauke]

@mbgower

So, first, do you agree that what we're proposing here is closer to that vision? We get to toss out the whole cumbersome definition of offset, for one thing.
[...]
I hope you'll agree that with a few illustrations, this new wording should be much easier to convey to users, while not actually changing the basic goal you were intoning in that old list.

oh, for sure. target offset was a weird and cumbersome neologism to start with, and the concept that it tried to convey was cumbersome in how it was trying to square the circle (hah) of "we can't really define a true minimum size, so we'll try and lump size and spacing together somehow"

To me, what has changed is that the language of the SC got firmed up [...]

Sure, to be clear, I was just trying to work out what led us to 2+ years of noodling around with the concept of target offset and trying to make it work, with much energy being expended on it...

[detlevhfischer]

What I find odd is the bit "another circle or target". Why "or"? Don't target and circle belong together always and are just one unit for purposes of measurement? Should this read instead "none of the circles intersect a circle on any other target"?

[patrickhlauke]

Don't target and circle belong together always and are just one unit for purposes of measurement? Should this read instead "none of the circles intersect a circle on any other target"?

@detlevhfischer but with your suggested rewrite, you're just looking at the circle, whereas the original wants you to also check the other targets themselves, which I think is the correct approach here (otherwise a 1x1 target could be right next to a large 150x150 target, and it would be fine because the first target's circle centered on that single pixel would not overlap the circle centered on the large target and be valid)

[detlevhfischer]

@patrickhlauke yes, I see, point taken.

[patrickhlauke]

note that, unless i'm getting confused, the new circle approach removes that weird "telescoping spacing" quirk that I documented ages ago for target offset (and recently made a new diagram for https://github.com/w3c/wcag/blob/e8b5883a42c8f1826616f6f7633cc912a0dfaf2b/understanding/22/img/target-size-toolbar-telescoping.svg) ... so at least there's one less counterintuitive aspect

[patrickhlauke]

heads-up that i'm working on an update for the understanding, including a clean (hopefully) diagram for the circle idea applied to the toolbar example. here's what I have so far...

(this here is a PNG converted version of a proper SVG)

[patrickhlauke]

work in progress on the companion understanding update #3103

[JAWS-test]

@patrickhlauke I would remove the circles in the top line of the graphic, because the targets are 24x24 px and therefore not measured with circles. Your approach suggests that the circles must always work, which is not true. In my example 1 and 2, the circle measurement would result in a violation, even if the targets were sufficiently large and fulfilled the SC.

[patrickhlauke]

@JAWS-test fair point yes, the top should not have the circles version at all to drive home that at 24x24 is actually quite small (at 1 to 1 scale) but you don't have to worry about the circle bits, and only if you then go even smaller, you have to start engaging with it.

[patrickhlauke]

tweaked it on #3103

also added some colour (with > 7:1 contrast ratio) and underline to the text bits to visually hint at what exactly it is that lets something pass/fail (complements the actual text that precedes/accompanies the diagram in the tweaked understanding doc itself)

[patrickhlauke]

i'm assuming this PR would be superseded by #3123 if that gets merged, right?

[alastc]

Superseded by #3123