[WCAG 2.2 Draft Feedback] Success Criterion 2.5.8 Target Size Minimum (AA)

[dshoukry]

“Success Criterion 2.5.8 Target Size (Minimum) (Level AA): 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;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• 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 or is legally required for the information being conveyed;

Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.”

Recommendation:
​​We kindly request that the group remove this SC until research is completed for all affected input and interaction modalities. Allowing smaller target sizes that are presented in isolation, alone in a part of a larger UI, may reduce usability rather than improve it by negatively impacting the findability of the target in question. We’d like to see both the SC and exceptions supported with more data, and the entire SC to be rewritten to clarify a minimum target size and padding, supported by empirical data, rather than a focus on target spacing. Defining a minimum target size is certainly very important. However, setting a too-small target size at an AA-level, and then trying to increase it later may have severe consequences.

Ultimately, this seems like an especially important area to have research, a diverse set of use cases, and a specific set of content structures to keep the SC beneficial, appropriately scoped, clearly testable and verifiable, and attainable.

Please find detailed specifics covered in our Sep22 2.5.8 Target Size Minimum (AA) Google Doc

[detlevhfischer]

Proposed Working Group answer:

---

The main concern in 2.5.8 Target Size is preventing accidental activation to support users with reduced motor skills. It also benefits users in situations where they are exposed to shaking, e.g. on public transport. The gestation process of the SC went through various iterations of trying to define target size, including setting a minimum size independent of spacing. It appeared that this approach had disadvantages as it would not cover the various interactions of targets with adjacent targets in various situations, such as target overlaps or enclosure of targets in other targets.

While the SC in its current wording indeed allows for targets to be smaller than 24 x 24 pixels, it takes away the main incentive of reducing target size below 24 x 24 px since the way target size including offset is calculated rules out compressing or packing targets in order to cram more targets into the available viewport space. Very small targets, while not ruled out as long as the minimum inter-target spacing is adhered to, would decrease usability for all users, being hard to perceive/read. They are therefore unlikely design choices by authors in a situation where each target needs a total spacing of 24 x 24 px (including offset).

There is ample research into beneficial target sizes, and extant recommendations both in research and by platform providers that warrant defining minimum target size in a new SC 2.5.8. The target size of 24 x 24px was chosen as a workable compromise between extant recommendations of larger sizes (e.g., Apple’s iPhone Human Interface Guidelines recommend a minimum target size of 44 x 44 px) and the needs of interfaces where a lot of icon-based controls need to be simultaneously available (e.g., in toolbars), evidenced in many existing implementations of web-based applications.

[slauriat]

There is ample research…

The only research referenced in the Understanding Target Size points to one study specific to small touchscreen devices, while the SC applies to all devices and input modalities. If other research backs this guidance up across everything on the web, then linking to that as well in the documentation should cover this concern.

[dbjorge]

I agree that I would like to see the references in the Understanding Target Size document updated to include a broader set of research. In particular, while I agree with @slauriat that there should be citations that cover a broader range of input modalities and form factors, I also note that the single cited study doesn't include any study participants older than 42 - I'd like to see the SC justified by research that includes a broader representation of users.

[dbjorge]

Reiterating this comment from #2695 since I think it's probably better-suited here: I think the "Spacing" exception is especially problematic in that I think the only study referenced in the understanding doc actually provides direct evidence that contradicts the underlying assumption behind the exception!

The Spacing exception is built on the assumption that if a target is crowded by other targets, then a user would tend to press on a spot on the desired target which is further away from crowding. But figure 5 in section 5.1 of Target size study for one-handed thumb use on small touchscreen devices does not consistently reflect this assumption! In that study, only buttons that were crowded on their left sides reflected the assumption; for buttons that were crowded above and below, users actually tended to press towards the crowded side.

I think that adding more of these references that @detlevhfischer linked earlier would be sufficient to justify the 24 CSS pixel size choice, but I don't think any of those references support the Spacing exception, and I think the specific one linked above is evidence against the Spacing exception as-written (regardless of whether the changes in #2798 are accepted).

[alastc]

On the linked google doc, I didn't see anything more in there, it looked like a copy of the understanding document with no comments/changes, is that correct?

On the research, there are few points:

• There is ample research that bigger is better for targets (e.g. see Fitts law).
• There is ample research that people with motor impairments have a higher error rate, e.g. Mobile touchscreen user interfaces: bridging the gap between motor-impaired and able-bodied users.
• W3C members have their own platform guidelines that ask for a larger target area than this SC is asking for. Could the research that is based on be shared?
• For the web-content guidelines, we can take lowest common denominator approach, where a requirement for one scenario (e.g. tapping a target on a touch screen) can have a size requirement so long as it doesn't negatively impact other scenarios (e.g. clicking the same target with a mouse).

On the other points:

Allowing smaller target sizes that are presented in isolation, alone in a part of a larger UI, may reduce usability rather than improve it by negatively impacting the findability of the target in question.

This comment seems to be based on a previous version? There is nothing in the current SC that is encouraging smaller targets, it is a minimum, not an ideal size.

setting a too-small target size at an AA-level, and then trying to increase it later may have severe consequences.

There is currently no intent to change the SC later, except perhaps as part of the WCAG 3 process. Could you explain what/why it would have severe consequences?

As mentioned, bigger is better but the size is based on web-practicalities, not the ideal size. It is intentionally a baseline size that does not harm (for example) people zooming into an interface with a toolbar. That is also true of the exceptions, they are there to account for things authors cannot adequately control, or whether there are other methods of achieving the same function.

[dbjorge]

Allowing smaller target sizes that are presented in isolation, alone in a part of a larger UI, may reduce usability rather than improve it by negatively impacting the findability of the target in question.

This comment seems to be based on a previous version? There is nothing in the current SC that is encouraging smaller targets, it is a minimum, not an ideal size.

The comment says "allowing", not "encouraging". The current SC's spacing exception allows a 1x1 px button (so long as it is at least 23px away from any other targets, ie, "presented in isolation").

That said, I do think the current spacing exception encourages smaller target sizes in some cases. For example, if an author has a goal of making a certain number of buttons fit side by side within a thin container, the current spacing exception makes that easier to achieve with smaller target sizes:

• 3 24x24px buttons with 0 space between them need 72px of total width
• 3 16x16px buttons with 8px of space between them only need 64px
• 3 8x8px buttons with 16px space between them only need 56px

[dshoukry]

On the linked google doc, I didn't see anything more in there, it looked like a copy of the understanding document with no comments/changes, is that correct?

Thank you for verifying if this was expected! I can view 23 comments in there from September 28 (and five on the first page alone). Could you please try loading the doc again?

On the research, there are few points:

• There is ample research that bigger is better for targets (e.g. see Fitts law).
• There is ample research that people with motor impairments have a higher error rate, e.g. Mobile touchscreen user interfaces: bridging the gap between motor-impaired and able-bodied users.

+1 to these points and the feedback raised by @dbjorge that (citing) more studies and research from additional populations would be helpful to ensure the decision is as robust as possible.

• W3C members have their own platform guidelines that ask for a larger target area than this SC is asking for. Could the research that is based on be shared?

We should be able to help with this after obtaining a few approvals. Would it be sufficient to share the study here and also attend an upcoming group meeting, similar to the Shadows and Outlines/Non Text Contrast approach from 2019?

• For the web-content guidelines, we can take lowest common denominator approach, where a requirement for one scenario (e.g. tapping a target on a touch screen) can have a size requirement so long as it doesn't negatively impact other scenarios (e.g. clicking the same target with a mouse).

On the other points:

Allowing smaller target sizes that are presented in isolation, alone in a part of a larger UI, may reduce usability rather than improve it by negatively impacting the findability of the target in question.

This comment seems to be based on a previous version? There is nothing in the current SC that is encouraging smaller targets, it is a minimum, not an ideal size.

Would the group consider dropping this to an A-level if this is the minimum, and using an AA-level for an ideal size?

setting a too-small target size at an AA-level, and then trying to increase it later may have severe consequences.

There is currently no intent to change the SC later, except perhaps as part of the WCAG 3 process. Could you explain what/why it would have severe consequences?

This is more in line with our concerns that the target size is quite small, especially at an AA-level. We are worried about the churn of having to retrofit targets after further research and consensus (hopefully) justifies a larger target size. :-)

[alastc]

Thanks @dshoukry, I can see the comments now. Not sure what happened before, they just weren't showing up for me.

Proposed response for group consideration, trying to avoid repetition with the replies above:

---

We kindly request that the group remove this SC until research is completed for all affected input modalities.
and:
+1 to these points and the feedback raised by @dbjorge that (citing) more studies and research from additional populations would be helpful to ensure the decision is as robust as possible.

and

This is more in line with our concerns that the target size is quite small, especially at an AA-level. We are worried about the churn of having to retrofit targets after further research and consensus (hopefully) justifies a larger target size. :-)

The understanding documents have not been repositories of research, they are intended to be concise how-to guides for understanding and meeting the SC. Perhaps we should link to the Mobile Accessibility Task Force's original searches?
https://www.w3.org/WAI/GL/mobile-a11y-tf/wiki/Summary_of_Research_on_Touch/Pointer_Target_Size

Given that most guidance (including from Google) is for larger target sizes than the minimum required by this SC, what could more research show that would change the SC?

The restrictions on this SC are more about web practicalities than the user-requirements. For example, WCAG doesn't (and cannot) differentiate between web sites that are used on mobile compared to desktop. Therefore everything has to be compatible with both.

Unfortunately, because of those practicalities there is no research that would lead to a blanket requirement for a larger size. In a future version (e.g. WCAG 3) there could be a more nuanced SC which has different size requirements for different controls.

Clarify that “size” is referring to “target size”, not necessarily “visible size”. In particular this is explained in the exception for Spacing, but given that this is such a key part of understanding the SC, we feel it might be clearer if it was a core part of the requirement and not an Exception.

The SC starts with "The size of the target", and the target is a link to the definition ("region of the display that will accept a pointer action"), so it is currently part of the core SC requirement.

Article (exceptions) should clarify if these guidelines apply to custom styles for scrollbar thumbs/handles, and/or if there are any special considerations in that case.

All of WCAG applies to the web content, not browser chrome. If the target is a scroll bar within the content (e.g. scrollable element), then it would apply. That is the same for non-text contrast, keyboard accessibility, pointer gestures etc.
That's an example that could be added to the understanding document.

How was this (spacing) exception (the note) determined? We have some concerns about the accessibility of targets being spaced out 24px with a target size potentially being allowed at 1px.
Allowing smaller target sizes that are presented in isolation, alone in a part of a larger UI, may reduce usability rather than improve it. This exception has the benefit of potentially meeting the intent of the SC (i.e., reducing the number of accidental hits of an adjacent target), but may risk reducing usability by negatively impacting the findability of the target in question.

The exception came from the prioritisation of not making accidental hits, and that allows for more flexibility. Obviously we do not wish to encourage small targets, but that comes from WCAG defining a baseline rather than a goal.

Suggest "meets this criterion with no exceptions" (for the equivalent exception). By a strict reading or perhaps just through gaps in testing this standard seems to allow two equally problematic controls. What if the other target has an essential exception for some reason? If another control "meets this criterion", then that makes it so that the original control ALSO meets the criterion, setting up a potentially problematic loop.

If a target uses the "essential" exception, I don't think it could have an equivalent control elsewhere. By the definition, anything that meets the essential exception "cannot be achieved in another way that would conform".

Would the group consider dropping this to an A-level if this is the minimum, and using an AA-level for an ideal size?

We aimed for that with the WCAG 2.1 SC for target size, but there are just too many interfaces on the web with smaller targets that would require a complete overhaul and negatively impact other audiences. (Including online document editors.) That requirement is at AAA.
Effectively we already have done that, but at AA and AAA.

This (User-agent exception) implies that if the browser fails this, then the content authors must fix it. This conflicts with other guidance like "1.4.13 Content on Hover or Focus".
Changing it to "…by the user agent and is not modified by the author" would work...

That is the text in the document (and the up to date SC text).

This (note) should probably specify that the spatial selection is a continuum. A block of cards with 1px radio buttons for selection would pass the standards, even if the targets are a tiny portion of the whole display. This could even encourage creators to reformat things in this manner to bypass other requirements. Many sliders also only have discrete, individual targets for their marks, and can only be clicked in certain places. Controls can be formatted in a way that undermines their own function, and we shouldn't have an exception because it looks a certain way.

The note is describing what is considered a target. For example, the entire editing area of a document is considered 'a target'. However, it also allows the selection of a location within that target area. It would not be feasible to make every possible cursor position 24px wide. A volume slider with 100 options would have to be 2400px tall (or wide), which is also not feasible.

We did consider trying to specify a continuum, but it didn't help. E.g. if 1px selection are the smallest possible option, when is it not a continuum? 2px, 3? Not including this clarification appears to do more harm than good (balancing real uses of it verses potential gaming).

We are interpreting there isn't a true minimum target size in this standard.

Technically true, but it is structured and described in a way to encourage larger sizes rather than using spacing.

“Spacing” and “target offset” seem to be used interchangeably for the same concept. One term should be used to reduce confusion.

Target offset is the measure to determine if there is sufficient spacing. That section of the (understanding document)[https://w3c.github.io/wcag/understanding/target-size-minimum.html] has been updated.

This (user-agent exception) seems like an opportunity to either push the browser to update to a more accessible default, or to recommend more accessible alternatives. Ideally, some course of action that would maintain a11y would be desirable.

That would be ideal, but if we can't rely on that by publication date, we can't fail authors for browser issues.

Can you provide reasoning as to why? (zoom isn't a mechanism to pass.)

If zoom were a way to pass, nothing would fail. There would be no point in creating the SC. Also, having to zoom in to use targets may itself be difficult for people with mobility impairments, e.g. pinch zooming with tremors.

An illustration could help clarify what is meant by this exception: "The requirement does not apply to targets while they are obscured by content displayed as a result of a user interaction or scripted behavior of content"

It isn't an exception, just outlining that content layered above a target doesn't impact how you assess that target. I.e. partially obscuring background targets doesn't suddenly make them fail.

Agree that a visual example would help, something has been added to #3027

This (text about passing with spacing) is again related to the distinction between “target size” and “visible size”. This clarification essentially states that a target doesn’t need to be both 24 CSS pixels tall and wide; it only needs to be one of them - 24 CSS pixels tall or wide - provided that the other dimension doesn’t have adjacent targets.

I think this is a misunderstanding, but I'm not sure how to prevent it. There is no mention or differentiation of the visible size of targets. It also doesn't differentiate between height and width. It could be less than 24px on both axis, if there is sufficient spacing on each axis.

We are interpreting this new draft that this SC is not about ensuring a minimum target size; it’s about ensuring a minimum distance between adjacent targets, as illustrated by Figure 8 and Figure 9.
A description could be something to the effect of:
"Accessible targets for any pointer input must allow a X by X CSS pixel square to be overlaid on top of that target along all possible dimensions [include illustration], without overlapping any adjacent target."
The description above with Figures 8 and 9 may be a more clear way of describing the standard and its intent than the current version.

and

The definition of “spacing”/”target offset” is atypical for web development: “measures the distance between targets, measured from the farthest point of one target to the nearest point of the adjacent target”. In particular, very few web layout considerations are from the “farthest point” to the “nearest point”, potentially making this difficult to both understand and test. Instead, consider using more standard relationships like padding and margin (e.g. “if the distance between each target such as margin or padding, combined with the height of each target, meets or exceeds 24 pixels”).

The earlier versions of the SC did describe it as minimum size OR size and spacing. However, it was simpler and conveyed the intent to start with a minimum size.

We tried several variations of 'put a square over the target', and others, in this (experimentation doc)[https://docs.google.com/document/d/1qhh9VgBC_6HD2emkvql2Hn83iSChwlhGBs5_E9gkdEM/edit]. It is ok for a minimum size, but it leads to odd results for spacing, particularly in rows of targets.

This example seems to duplicate much of the information above and seems to add more word count without necessarily adding more value. Recommendation would be to clarify the core content above in order to trim this content.

Most of the examples have come from questions people have had, but we will do a review of the whole before the next stage.

This example uses a picture of text to illustrate the exception for inline targets. A text example (rather than a picture of text) may be more clear and accessible

We have removed those examples as the updated "inline" exception covers those.

Please consider the impact that smaller icons could have on certain users, such as those using head-mounted pointing devices, or with fine motor control challenges where the user perceives that they must click a very small target (even if the actual clickable area is larger due to invisible clickable padding, etc.)

The example (with the media controls) is there to assist people testing the SC. It is not trying to encourage smaller targets, in fact it saying that smaller targets (that pass) will negatively impact the layout.

Would the group consider dropping this to an A-level if this is the minimum, and using an AA-level for an ideal size?

We started at 44px at AA, but couldn't work around objections based on legitimate cases where targets needed to be smaller than that (including for people with low vision).