Wcag: Pointer Target Spacing (2.5.8), user agent defaults, and lists of links/controls

[jared-w-smith]

If an HTML list that contains links has browser default CSS for sizing, does this fall under the "User Agent Control" exemption for Pointer Target Spacing? I don't know how it couldn't - the target sizes and spacing would entirely be user agent defined.

What about groupings of unstyled checkboxes and radio buttons separated by line breaks?

If the answer is yes and an unstyled list of links/controls passes, would it then fail if the user increased the text size or spacing to make the target spacing larger, but still <44px? If so, this seems a bit odd and would suggest that smaller, default targets are more accessible than larger, customized targets.

I have a basic example file that demonstrates this at https://webaim.org/temp/targetspacing.htm

@patrickhlauke pointed out that the WCAG TOC links do not meet Target Spacing requirements:

Similar lists of links are present, for example, in the linked Editors names at the top of the WCAG 2.2 document, lists of Technique resources, the lists of navigation links in the w3.org side bar navigation and footer, lists of W3C mailing list messages/threads, etc., etc., etc., etc.. Of note is that nearly all of these have spacing that is larger than the browser default. Such lists are _extremely_ common - and rarely meet the 44 pixel spacing requirement. In fact, outside of WAI pages, I found it difficult to find such lists of links that do conform.

If these do indeed fail, then the easiest solution to make them pass would be to remove the custom spacing and revert to the default, much smaller, spacing, so they would then (presumably) be exempted. An alternative approach for the WCAG TOC is to significantly narrow the sidebar or add additional text to each link so that each link wraps to more than one line, thus resulting in a larger target area (and thus target spacing). Or, as I've noted elsewhere, the text can be made smaller (8px text in the WCAG TOC would provide 44 pixel target spacing in all instances).

These 3 different methods for easily passing this SC arguably result in a less accessible and usable experience. WebAIM's recommendation remains - this SC would benefit from additional clarifications and better-defined scoping, and/or should shifted to Level AAA.

[patrickhlauke]

a note just on "default CSS for sizing" - there is no such thing unless you're using a completely unstyled page. As soon as you do anything like set the font face, base size of text for the page, etc, you're potentially off the default.

[jared-w-smith]

a note just on "default CSS for sizing" - there is no such thing unless you're using a completely unstyled page. As soon as you do anything like set the font face, base size of text for the page, etc, you're potentially off the default.

Correct, but it would truly be punitive and rather arbitrary to have WCAG fail content when the author has applied CSS that results in the exact same target size/spacing as the default, no?

But the more important point is that this SC would fail content that the author customizes to be much better than the defaults (but not >=44px), yet it would presumably not fail content that retains the much smaller default styles.

And more important still is that this would render most pages with lists of links or stacked default inputs non-conformant with Level AA, and thus potentially legally liable. This would include the homepages of both of our employers, not to mention WCAG and W3.org. I can easily see this causing the most sweeping increase in non-conformance that WCAG 2 sub-versions have introduced. I'm not opposed to this obvious improvement to accessibility, but the vast impact on authors should be considered and weighted with some measure of the end user impacts/benefits.

[patrickhlauke]

oh, i think we're exactly on the same page here Jared. this is by far the most disruptive SC of the recently proposed ones, with an impact on most of the web as it is today, requiring huge amounts of redesign. seems to me that either it needs to be very tightly scoped (which then, I fear, will end up with arbitrary-looking lists of "except when it's this, or that, or that, or the other" ... just because it can't say "do this only to the most important controls" as "important" is not unambiguously definable), or moved to AAA.

[jared-w-smith]

The end user impacts of targets on subsequent lines is typically much lower because the link texts or inputs (and/or their labels) are typically of different lengths, so there are often portions of them that would meet the 44x44 pixel spacing, even though the entire target typically would not.

As an example, on my example page, while the middle items in all 4 examples do not currently have 44 pixel spacing, they do have substantive portions of the labels and link texts that do have 44 pixel spacing due to their varied lengths.

I suggest the following new exemption:

Subsequent Lines: The targets are located on subsequent lines and the line spacing is at least 1.5 times the text size.

This would ensure much larger spacing (50% more than default) is provided, but would not result in as many websites suddenly failing this new Level AA SC for lists of links/controls, one of the most common and foundational components of web content.

The proposed wording likely needs some tweaks and the "1.5 times" is just a guess at a reasonable value, but I think this would provide a compromise that might receive wider support.

Thoughts?

[patrickhlauke]

personally not a fan of adding more exceptions...

Subsequent Lines: The targets are located on subsequent lines and the line spacing is at least 1.5 times the text size

this would then hinge on how you define "lines". are these not also "lines"?

and as those all span the width, there won't be that "are typically of different lengths" escape clause either.

they do have substantive portions of the labels and link texts that do have 44 pixel spacing due to their varied lengths

define "substantive"

[edit: i hope you don't now just make up an arbitrary percentage of the overall surface area of the clickable area, or some such...the last thing we need is more super-complex calculations that are needed for determining pass/fail ... (whispers something about the burden of testing)]

[jared-w-smith]

this would then hinge on how you define "lines". are these not also "lines"?

They look like subsequent lines to me. I don't think this is any more ambiguous than "inline" is currently. "Line height/spacing" is in two other success criteria without definition.

and as those all span the width, there won't be that "are typically of different lengths" escape clause either.

Correct. But this isn't an "escape clause". It instead just provides _some_ justification for allowing smaller target spacing for lists of links/inputs because in _some_ cases they would have portions that do provide 44 pixel spacing.

define "substantive"

This term isn't at all relevant to my proposed exemption, so needs no formal definition.

i hope you don't now just make up an arbitrary percentage of the overall surface area of the clickable area, or some such

Not at all. Again, surface area isn't relevant to my proposal. What is relevant is requiring spacing between lists of links/inputs that promotes better accessibility, but is also reasonable. This SC seems (I think - nobody has yet answered this initial question) to allow default spacing which is extremely small and would never pass, but would not allow any spacing this is greater than the default unless it is also >=44px (which designers/UX will likely view as absurdly large for such things).

I'm just trying to find a way to possibly salvage this success criterion, because I see little chance it will be widely accepted or adopted as is.

[patrickhlauke]

this isn't an "escape clause". It instead just provides some justification for allowing smaller target spacing for lists of links/inputs because in some cases they would have portions that do provide 44 pixel spacing

but then that justification doesn't exist for that case, which you say would still fall under the "lines" case. so it's an inapplicable justification in that case, which is not a good start for some solid exemptions.

I'm just trying to find a way to possibly salvage this success criterion

yeah, sorry, i'm being overly harsh. good to chew these things over either way

[detlevhfischer]

Proposed working group answer:
Thank you for your comments.
We acknowledge the concerns you have raised here and in issue #1361
The Working Group has opted to re-draft this SC. We aim to remove the incentive of reducing target size in order to compress groups of elements and 'save space'. We also acknowledge that for very common patterns like drop-down menus or tables of contents, the general requirement of a minimum of 44 x 44px for target and spacing may be unreasonable and will also have negative side effects (fewer elements of vertically stacked structures visible in the viewport, reducing overview and requiring more scrolling).

[alastc]

The mobile task force have proposed this update:

For each target that has a width or height less than 44 CSS pixels, the target area has a width and height of at least 24 CSS pixels with a minimum spacing on the height and width of 4 CSS pixels where the spacing cannot overlap.

• Inline: The target is in a sentence or block of text;
• Essential: A particular presentation of the target is essential to the information being conveyed.

I think it might need some tweaking so that (for example) a 28px (or larger) target is obviously ok, but does this formulation/requirement address the issue here?

Kathy from the TF noted: "The 24 CSS px comes from Microsoft’s research where they are recommending a target area of 24px with a minimum of 16% spacing. If we look at the minimum that is 3.8px so we rounded that to 4 CSS pixels."

[detlevhfischer]

Unfortunately I couldn‘t make it today to the MATF telco, but here are two things that we may still need to address:

1. “with a minimum spacing of the height and width of 4 CSS pixels“:
   I think the current wording does not clarify whether 4 px spacing is the combined value for width (e.g. 2 px left and 2px right) or whether 4px would be required all around the target. Can we clarify that?
2. For designers aiming for more compact icon bars or dropdown menus, this approach seems to encourage a pattern of 24px width / 4px space (or 8px, see above) / 24px width and so on. I contend that 28px width flush 28px of the adjacent target might be the preferable implementation as it increases chances of hitting the target - at least in the mouse pointer space where no tab heuristics apply. What is the rationale of preferring smaller targets with gaps over larger targets without gaps if both have the same size and take the exact same space (assuming that many targets will have some padding which would be part of the target area)?

[detlevhfischer]

So an approach could be: go for 28p x 28px (or 32x32?) or, if you must have smaller targets, then make them not smaller than 24 x 24px plus spacing (still uncertain whether 4px total or each side)

[jake-abma]

Detlev, in short, a 30x30 would require a 4 px spacing NOT overlapping and
thus having 8 CSS px target spacing

This for all targets between 24 and 43, where the 36 to 44 sizes should
have a adjustment in the text I do not see now (a max need up to 44?!)

Op do 10 sep. 2020 om 19:36 schreef Detlev Fischer <[email protected]

:

So an approach could be: go for 28p x 28px (or 32x32?) or, if you must
have smaller targets, then make them not smaller than 24 x 24px plus
spacing (still uncertain whether 4px total or each side)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1384#issuecomment-690546991, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQWTATGTJUQM22AB4XL7V3SFEFBRANCNFSM4QVIGMUQ
.

[jake-abma]

So, I mean, only a minimum of 28 would not tackle this...

Op do 10 sep. 2020 om 19:44 schreef jake abma [e-mail]:

Detlev, in short, a 30x30 would require a 4 px spacing NOT overlapping and
thus having 8 CSS px target spacing

This for all targets between 24 and 43, where the 36 to 44 sizes should
have a adjustment in the text I do not see now (a max need up to 44?!)

Op do 10 sep. 2020 om 19:36 schreef Detlev Fischer <
[email protected]>:

So an approach could be: go for 28p x 28px (or 32x32?) or, if you must
have smaller targets, then make them not smaller than 24 x 24px plus
spacing (still uncertain whether 4px total or each side)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1384#issuecomment-690546991, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQWTATGTJUQM22AB4XL7V3SFEFBRANCNFSM4QVIGMUQ
.

[detlevhfischer]

@jake-abma can you clarify where the 30x30 come from? 24 plus 4 plus 4 is 32?
You wrote

a 30x30 would require a 4 px spacing NOT overlapping and thus having 8 CSS px target spacing

I am unclear now whether you intend to require an extra 4 px spacing all around for anything smaller than 44x44 - that would mean for a target of 43x43 that you must have extra spacing of 8px combined on top of that?? I.e. an overall space requirement of 51X51 for target and (non-shared) spacing? I hope that I am mistaken here... because that won’t fly for sure.

[jake-abma]

it was just an example, all sizes between 24 and 43 are applicable...

SO only setting the size at 28 instead of 24 is not an option...

Op do 10 sep. 2020 om 20:13 schreef Detlev Fischer <[email protected]

:

@jake-abma https://github.com/jake-abma can you clarify where the 30x30
come from? 24 plus 4 plus 4 is 32?
You wrote

a 30x30 would require a 4 px spacing NOT overlapping and thus having 8 CSS
px target spacing

I am unclear now whether you intend to require an extra 4 px spacing all
around for anything smaller than 44x44 - that would mean for a target of
43x43 that you must have extra spacing of 8px combined on top of that??
I.e. an overall space requirement of 51X51 for target and (non-shared)
spacing? I hope that I am mistaken here...becaus that won’t fly for sure.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/wcag/issues/1384#issuecomment-690594081, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/ABQWTAX3NHSL6F6X52S5JVLSFEJM7ANCNFSM4QVIGMUQ
.

[detlevhfischer]

Rereading what you wrote about the range of 36-43, that it would only need spacing to add to the combined target/spacing width of a max of 44 and not beyond, that would still penalise those that want a 32x32 target without spacing rather than a 24x24 taeget with spacing (which visually could look exactly the same). Because if I understand this correctly, you couldn’t have a 32x32 target row flush, you’d need to add 4px (not shared) i.e. have an extra gap of 8 px between each 32px target, cranking up total width to 40. Is that intended, in the light of the pushback we had about things like drop-downs and TOCs? I hope I still misunderstand.

[patrickhlauke]

I mentioned this on the MATF list, but I'll reiterate it here as well: it seems that the values were at least in part inspired by https://docs.microsoft.com/en-us/windows/uwp/design/style/app-icons-and-logos#more-about-app-icon-assets - but note that these values aren't based strictly on Microsoft's research, but are specific guidelines for making app icons in Windows (for instance in the Windows Start menu, which is tile-based and relies on a particular grid) look good and consistent.

[jake-abma]

I also mentioned this on the MATF list:

Basically we've tried to solve the User / Functional Need / fix the intent of activating the wrong link by providing target spacing IF targets are less than 44 CSS pixels.
(so not setting a minimum target size, this might be an option but just want to be clear on preventing the accidental activation of small targets)

We've come up with two approaches last year where we need to word it in a way to solve different scenarios.
Hereby two ways of looking at it, not perfectly, but to give an idea on the challenge we need to solve in a beautiful sentence.
This is not per se a suggestion but an addition to show the two ways of approaching this:

(Again, a SC for setting a minimum target size might be made (or integrated in this one) but the 44 px was already that one not ending up at AA, if we want one smaller than 44 this might be done without blending it with this User Need / intent)

---

1 (all possibilities smaller than the AAA version)

The width and height of targets and their target spacing is at least 44 CSS pixels where spacing between targets do not overlap, except when:

Inline: The target is in a sentence or block of text;
Essential: A particular presentation of the target is essential to the information being conveyed.

---

2 (8 px with fix for grey area)

There is 8 CSS pixel target spacing for each target smaller than 36 CSS pixels
AND FOR
Targets between 36 and 44 CSS pixels the Total of target and target spacing is at least 44 CSS pixels,
except when:

Inline: The target is in a sentence or block of text;
Essential: A particular presentation of the target is essential to the information being conveyed.

[detlevhfischer]

Two bits from the MATF minutes:

I do think that some spacing is needed between targets.
the whole idea with the spacing is to avoid touching two targets at the same time

The following image illustrates the point I am trying to make:

_Alternative text:_
_The image shows two versions of a row of six icons which to the user look identical, but differ in terms of target size. The target size is indicated here by a turquoise background.
The first implementation has targets of 30 x 30 px, with 4 px spacing all around (spacing not shared) - a PASS according to the latest MATF wording
The second implementation has bigger targets (target width = 38 x 38 px) and no spacing - a FAIL according to the latest MATF wording._

I am still looking for a rationale why having spaces as in the first row in the image above is better (would pass) compared to having larger targets without spacing (which would fail if I understand correctly the current MATF proposal). Is there any empirical evidence that having empty space between targets that are smaller is better than having larger targets?
If there is no clear evidence, I think that implementations that avoid spacing as in the second row should not be penalised. This may be particularly important for drop-down lists where having empty space between options (rather than indicating that as you cross into the next target, the focus changes) seems to me like an antipattern that this SC would enforce in its current shape.

[alastc]

There is 8 CSS pixel target spacing for each target smaller than 36 CSS pixels
AND FOR
Targets between 36 and 44 CSS pixels the Total of target and target spacing is at least 44 CSS pixels,
except when:

So I could have a 4px target with 8px of spacing and pass, but if it's a 36px target with 6px spacing it fails?

I don't think that sets up useful incentives with regard to spacing.

At least having a minimum size (even thought it's not as big as we'd like) is simpler work out and shows a pathway to 44px at AAA, and it would catch the worst examples.

[detlevhfischer]

@alastc „4px target“ may be a typo? Did you intend to write „24px“?

[alastc]

No, 4px is a "target smaller than 36 CSS pixels", an extremely small one!

[jake-abma]

Of course we've been through this and also all kind of examples, all variations have passed by already at least once.

My text was not a suggestion but a challenge to be solved, see "This is not per se a suggestion but an addition to show the two ways of approaching this:"

When you start to mix spacing with size, trouble is introduced as different sizes suddenly / compared to each other, seem to have an 'unequal' rule applied. This is where the " there is an area with a width and height of at least 44 CSS" was introduced.

In short (hope it will be short :-) ) again the challenge:

---

Intent 1 / user need 1:

1: a base target size large enough to activate

WCAG 2.1 AAA, we created 44x44 and it didn't make AA

---

Intent 2 / user need 2:

2: if targets are too close AND NOT 44x44 they need spacing to prevent accidental activation

WCAG 2.2, how to solve this?

Now if we demand only spacing, we'll get question like the one from Alastair like is a 4px target with 4 px spacing OK? Or is a 16px target with 4px spacing OK? etc.

But if we have a minimum size, like 24px, than you get questions like from Detlev: is 24 + 4px spacing OK, why not a 28 without spacing?

Also spacing can 'overlap' or margins can collapse, is that ok?

Or 4 px spacing on each side without overlap, minimum of 24px, BUT what about 40 px targets? Including a 4 px spacing on each side will make them 48 px and this is more than the 44 target size at AAA. So what is the rationale?

And if we set a target area / target combined with spacing, we'll get the remarks present now for the draft.

---

So to me it seems like OR we will add a "AA" target size (which is weird as the 44 is what we tried, so now we lower the bar based on what exactly?) OR we set a target spacing (as this was the basis of this SC) and do not care about differences in target size OR define a minimum size and spacing, but we will have to solve all grey area or we keep on getting people asking about the comparisons of different sizes and the un-equality.

(making a AA target size is the most easy way out, but doesn't solve accidental activation of stacked target only 24, or 28, or 30 px... making the intent not honored)

[detlevhfischer]

@jake-abma I‘m not sure what you mean by

making a AA target size is the most easy way out, but doesn't solve accidental activation of stacked target only 24, or 28, or 30 px... making the intent not honored)

Stacked - if you mean targets overlapping, I guess calculations should only account for those target areas that are not covered by other targets higher up in terms of the z-axis.

If designers use transparent overlapping targets so you don’t know what you are hitting, that will be a usability problem for all. I doubt that this will occur often (but it might be encouraged if automatic tools turn out to be too thick to account for target overlaps)...

To prevent unintended consequences like the reduction of target size to make targets fit into confined spaces, I have personally come to the conclusion that a straightforward size requirement (with the same exceptions as the current AAA SC) will be both easier to understand and less likely to encourage weird approaches just to nominally conform.

[jake-abma]

@detlevhfischer no, I just meant target directly next to each other, list of links (not on top of each other in layers)

below the 44 px the possibility of activating the wrong one increases, so only a minimum size of 24, or 28 or 30 will not solve this barrier

[detlevhfischer]

@jake-abma I think there is the general trade-off between (1) of how many entries in a dropdown you can see without having to pan/scroll and (2) target height of each entry. I take it that tap heuristics on mobile mean that it won‘t be any better to have a 20px height menu entry with 4px top and bottom, compared to a 28px height where targets are flush.
(And mouse users don’t suffer from the „fat finger” problem, at least.)

And I do think that having a lower boundary like 28px will prevent really bad / tightly stacked / tiny target sets).

[jake-abma]

I think we all agree, but the question remaining is: what barrier are we trying to solve, what exactly is the intent, and what SC criteria will we agree on.

Is there really so much targets out there smaller than 28px, is 28 the right number? where is the data we base the SC on? And, is this solving the intent of where we started with this SC (or did it morph into something else?)?

Any 'refreshed' suggestions?

[alastc]

Hi everyone,

Kathy Wahlbin said:

---

The mobile accessibility taskforce is recommending the following changes to target spacing SC.

The size of the target for pointer inputs is at least 26 by 26 CSS pixels except when:

• Inline: The target is in a sentence or block of text;
• User Agent Control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential to the information being conveyed.
  

  ---

So taking a smaller size approach for level AA.

[patrickhlauke]

The size of the target is determined by the user agent and is not modified by the author

noting that this exemption would not apply as soon as anything like font size - and in the case of mobile/tablet browsers, viewport meta - has been modified by the author

[alastc]

@patrickhlauke - I don't understand the viewport meta aspect, on the face of it that doesn't appear to change the default size of the element (in CSS pixels).

[patrickhlauke]

ah, you're correct ... was clearly thinking about the actual real-world effect here, rather than the CSS dimensions one

[alastc]

Hi everyone,

The text of the success criterion has been significantly updated, and the group believes it resolves the issue so this issue is being closed. There will be another review opened soon.