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

[dshoukry]

“Success Criterion 2.5.8 Target Size (Minimum) (Level AA): Targets have an area of at least 24 by 24 CSS pixels, except where:
Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
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.
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."

We kindly request significant changes to this SC. Can the group share the research, data, or decision making process that influenced the decisions to drop the requirement from 44x44 in the FPWD to 24x24? This seems like an exceptionally small target at the AA level. We also have some concerns about the small size mobile/touch screens, and that focusing solely on web+cursor could be harmful to mobile UIs. Other than that, we have a few concerns about some of the provided exceptions and a UX writer found a few minor typos.

Please find detailed specifics covered in our 2.5.8 Pointer Target Spacing (Level AA) Google Doc.

[patrickhlauke]

Can the group share the research, data, or decision making process that influenced the decisions to drop the requirement from 44x44 in the FPWD to 24x24

noting that if an SC that demanded 44x44 was introduced right now, the vast majority of sites would immediately fail (including the W3C site, this very site here, etc).

focusing solely on web+cursor could be harmful to mobile UIs

the SC applies to all pointer types (touch, mouse, stylus, etc). it is not scoped to just perhaps the mention of "cursor" in the note led to some confusion? that part refers to the typing cursor / insertion point that you position inside a large editable / text area (positioning can happen with mouse, touch, etc)

[alastc]

Can the group share the research, data, or decision making process that influenced the decisions to drop the requirement from 44x44 in the FPWD to 24x24

Remembering that WCAG criteria are a 'must', many site would struggle to meet 44x44px. For example, the toolbar in Google Docs, the "back to Mail" links in iOS, the W3C site, etc.

Although Apple, Google & MS all have "guidelines" recommending 44/48px sizing, they are not met by the organisations themselves. That is ok when it is recommended guidelines, but in a context where people get sued for not meeting WCAG criteria, we have to make allowance.

We also had feedback from a low-vision user who did not want to loose items in the toolbar when zoomed in, as larger targets would take more space.

We also have some concerns about the small size mobile/touch screens

Our scope is web-content, we cannot differentiate by device any more than authors can restrict which devices use their website. The criteria has to apply across desktop & mobile (and everything in-between).

[eaugustine]

So is it 44x44 or 24x24 that is being proposed? Here it says 24x24, but here it says 44x44 (and confusingly, shows the 24x24 images).

I know this is a draft so I'm assuming these items would be updated. Another point of confusion for me was the section below showing that the last row of icons fails, but the text states that it's because they're stacked on top of each other, which they are not. I would expect it fails because they're not 24x24.

[patrickhlauke]

So is it 44x44 or 24x24 that is being proposed? Here it says 24x24, but here it says 44x44 (and confusingly, shows the 24x24 images).

the working draft lags behind the editor's draft - see https://w3c.github.io/wcag/understanding/target-size-minimum.html

[alastc]

I think the example is ok, it is showing examples for:

• Above 24px, therefore passes;
• At 24px, passing;
• Under 24px, but with spacing, so passes;
• Under 24px without spacing, so failing.

I'd like to know where you found the link to "Pointer target spacing", as that is not linked to from the WCAG 2.2 document. That is a left-over from a previous version from last year. We need to clear that out anyway, but it shouldn't be linked to anywhere.

[eaugustine]

My issue was not about whether the examples pass or fail—Pass/Fail are indeed labeled correctly. The issue is that in the Target Size page, the text below incorrectly describes the image, saying that the final image has buttons stacked on top of one another, which it doesn't.

The other issue is that in the Pointer Target Spacing page, the images do not reflect what is in the captions, stating 44x44 in the captions, but 24x24 in the images. For example:

I found the link to Pointer Target Spacing from this page.

[patrickhlauke]

My issue was not about whether the examples pass or fail—Pass/Fail are indeed labeled correctly. The issue is that in the Target Size page, the text below incorrectly describes the image, saying that the final image has buttons stacked on top of one another, which it doesn't.

The text there refers to "The next two illustrations". i.e. Figures 2 and 3. NOT figure 1. and in Figure 3 the buttons are indeed stacked.

The other issue is that in the Pointer Target Spacing page, the images do not reflect what is in the captions, stating 44x44 in the captions, but 24x24 in the images.

That page https://www.w3.org/WAI/WCAG22/Understanding/pointer-target-spacing.html is defunct, and should have been deleted (not sure why it hasn't). It will not be corrected, but will just disappear. It was superseded by https://w3c.github.io/wcag/understanding/target-size-minimum.html and the latter is what is used in the current working draft https://www.w3.org/TR/WCAG22/#target-size-minimum (and https://w3c.github.io/wcag/understanding/target-size-minimum.html in the editor's draft https://w3c.github.io/wcag/guidelines/22/#target-size-minimum). So th

[liacrl]

I would like to clarify a few points and suggest a few adjustments. I will use a simple 1:1 conversion from dp to css pixels, understanding this is not the most accurate but I believe it's good enough for this discussion.

• The touch target size recommended by Google's Material Design is 48x48 dp and so far applied mostly on mobile.
• Google has done extensive research to reach the 48x48 dp value both on mobile and recently on desktop and shared results at goo.gle/3y5crjs (from 4:20 to 7:22 for those interested in learning more).

I understand desktop web apps and sites have a more diverse and complex UI architecture and it would be challenging to enforce a 44x44px/dp guideline. The tradeoff to lower the value to increase the amount of compliant websites might be an ok tradeoff for now.

However, I strongly believe the 24x24px/dp on mobile would be harmful because the screen is smaller and the area of a finger is larger and less precise than a mouse cursor. Google's research also demonstrated significantly lower success rates in smaller tap targets on mobile compared to desktops.

Would the group be open to set 48x48px/dp for applications and websites targeting mobile devices? Or at least defer to the recommendation provided by Google and Apple for mobile apps?

[patrickhlauke]

Would the group be open to set 48x48px/dp for applications and websites targeting mobile devices? Or at least defer to the recommendation provided by Google and Apple for mobile apps?

• touch isn't purely on mobile. there are laptops and desktop machines with touchscreens
• the SC doesn't just apply to touch, but mouse/stylus as well (and no, you can't make "for devices with touch, use this measure; for mouse/stylus, use this other measure" guidelines, because it's not possible - particularly in multi-input environments - for an author to confidently predict what type of input will be used ... see also https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/)
• you can't scope the guidelines to only apply to small devices. nor is it possible to make some statement anchoring things on the size of the viewport, since that still doesn't actually say anything about the actual physical size of where the content is being viewed/used ... it could well be a very large screen, or it may be in a browser that is not running maximised, or at an already high zoom factor (in which case making the targets even bigger will be over-compensating and make everything much too big)
• Google and Apple themselves break their own suggested minimum sizes when it's appropriate (the classic example in iOS would be the small "< Mail" control in the top bar next to the signal/wifi icons, when you followed a link from an email and it opened a browser) - their guidelines are not absolute, but more recommendations that can be bent/broken depending on the specific circumstance. WCAG guidelines are binary, you either pass or fail, there's no wiggle room/nuance in most cases

[jenstrickland]

Draft proposed response:

---

SC 2.5.8 Target Size (Minimum) (Level AA) is a partner to SC 2.5.5 Target Size (Level AAA).

Regarding the size of 44 x 44:

• The minimum target size to meet Level AA is 24x24 pixels and includes a target offset of at least 24 pixels, with noted exceptions. There are some interfaces where smaller sizes are appropriate and necessary, for example the toolbars at the top of certain editing interfaces. However, this SC should encourage the move towards larger target sizes and offset spacing in redesign efforts, as appropriate.

• This SC 2.5.8 includes the range of pointer possibilities, from mouse to touch, with the mobility needs as a consideration.

• The SC 2.5.5 Target Size (Level AAA) may be perceived as an enhancement increasing target size to 44x44 pixels where that is appropriate to the interface.

• An additional point, interface and user needs would determine the use of 24x24 or 44x44, while the SC set the minimums for guidelines.

[alastc]

Noting for group members responding: this one needs you to review the document and propose changes or responses to multiple points, a general response is not suitable.