[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.

[DavidMacDonald]

Agreed response from the group:

---

Typos identified in the Google document, as well as minor changes to address some comments, have been updated as part of #2122

In addition to the issue comments above, specific comments were added inside the cited Google document about the Understanding document. The original comment question (Q) and response (R) are repeated here:

In addition to the issue comments above, specific comments were added inside the cited Google document about the Understanding document. The original comment question (Q) and response (R) are repeated here:

Q. What about mobile/touch screens? A large target size is critical for touch screens since they are smaller and our are relatively larger/have less precision than a mouse cursor or other pointer. Focusing solely on web+cursor could be harmful to mobile UIs.

R. Apple's 44px guidelines and Google's 48 px are for (finger) touch interfaces whereas WCAG applies to all types of input (touch, mouse, pen, etc.) It should be noted that many Apple and Google interface components don't meet their own size guidelines for various reasons. We have to be careful with Success Criteria because in many jurisdictions they will become law, not guidelines that can be broken when its appropriate.

There are studies that indicate many people with motor disabilities require 100px targets, in which case the Google and Apple guidance would not be sufficient.

This Success Criteria has been through several years of iterations. It provides a careful balance between the impact on Web design and benefit to users. Requirements that impact the visual design of web sites typically require more compromise.

This success criterion is basically saying: "Don't make really small targets". It should be noted that users can obtain further increases to target size size by zooming in when necessary.

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

Q. This seems like a very small target at the AA level.
Can you please share more information about why this requirement reduced from 44 in the FPWD to 24 here?
We ran some research and came to the conclusion that 44 might be too small in a few cases. We covered this in a recent I/O talk, "Designing A11y with Material Design". The recording of that event is available starting at 4:22, the following link will take you right to the start of this portion: https://youtu.be/nTNwZXVRGdY?t=262
We can try to work on getting the approvals to share more information about this research if that would be helpful to move to the larger size?

R. Let us measure all the icons in the toolbar of this Google doc. From our testing, most are roughly 24x24. On a Safari browser, the plus target to add a new pane is 24x24. Existing usable interfaces in the wild, both on the web and on major operating systems have well-established targets close to this size.
There is significant difference between recommended/best practice and required minimums. If we define a new requirement, we are forcing all UIs to change or fail compliance.
WCAG needs to balance, amongst other things, potential negative impacts when our guidelines force wide-scale changes to existing patterns. What are the effects on users if the google docs toolbar loses half its buttons AND doubles in size to accommodate that? What are the effects on certain users with disabilities?

R2. In regard to the specific Google research cited, one study on response time can help establish baselines for optimal usage in some contexts. However, the outcome of an exercise where users are asked to pick a bunch of targets as fast as they can does not reflect real user interaction in a variety of web contexts, nor does it necessarily follow that a specific reduction or increase in the size of one or more targets leads to a meaningful change to time on task. In short, it does not provide a rebuttal to the variety of factors the guidelines must take into account. WCAG standards try to find an elusive balance between benefits and negative impacts to various users groups and interaction considerations, the leverage provided by ATs, the likelihood of getting traction by authors, and the existing practices and content on the web.

Q. The wording here [item 2 of "There are three exceptions" list] confused a few of our readers. We couldn't understand if there is or isn't a requirement for inline targets in text to be a certain size.
The intro seems to say there isn't but then the corner cases read to us as requirements (or perhaps just recommendations?)
Could this be clarified and or reorganized? Thanks!

R. The list of 3 items are prefaced with "There are three exceptions". Each of the items matches the bullets in the exceptions in the SC. We've made some changes to make things clearer and have also added visual examples further in the document, illustrating these and put in cross references to those.

Q These exceptions [item 3 of "There are three exceptions" list] seem like very common patterns that would greatly benefit from accessibility guidelines. If they are exempt from this SC, is there another pattern that would be applicable?

R. One method to address the exceptions is for users to use magnification or resizing. Zooming increases the size of targets and text links. Resizing text alone increases the target of links. Similarly, zooming in on a map increases the space between pins. In addition, we've updated the Understanding document to reference the new 2.1 Text spacing requirement that ensures that the width of text links as well as the vertical spacing between them can be increased by the user.

[alastc]

The response above was agreed by the group today.

[liacrl]

I understand this issue is closed but just want to ask the group to consider units carefully when comparing numbers.

Google's recommendation for Android apps is 48 dp (Density Independent Pixels), and Apple's recommendation for iOS is 44 points - both units are different from each other as the physical size corresponding to a unit is calculated different and they also different from actual pixels. While the concepts are the same (trying to preserve physical size independently from device/screen), the conversion is different resulting in different sizes in mm for the same number used across units.

[patrickhlauke]

resulting in different sizes in mm for the same number used across units

the group is aware of this, but there is no current way for authors to control exactly what the size, as measured on screen, of any content is. however, in their intent and practice, 1 dp and 1 (apple) point (which also differs from the traditional unit of pt), come very close - and in some cases are even identical to - 1 CSS pixel.

CSS pixels, which should match the reference pixel (but this is left up to user agents and operating systems) are the only standardised measurement that web content authors can rely on / that is within their control (noting also that even attempting to use "physical" units in CSS won't work since for screen media they're still anchored on the reference pixel, and bear no relation to the actual size as measured on screen)

related: w3c/csswg-drafts#614