Success Criterion 2.5.8 - Touch Target Size (Minimum) - Level AA

[JJdeGroot]

Discussion:

1 May 2024

[Source](https://www.w3.org/2024/05/01-matf-minutes.html#t04) Joe: Pixel conversion: CSS pixel is the native density for the platform. JJ: We should align with WCAG2ICT I asked this question recently in the MATF slack channel. The consensus was the same - to see 24 pixels being equivalent to whatever the appropriate unit used for other platforms - for iOS this is 24 points and for Android this is 24 density-independent pixels. This is an approach Deque follows as well I believe. AA: should we just use mm on the screen, as specified by NN? WCAG2ICT notes: w3c/wcag2ict#293 (comment) JJ: Android can modify density, so perhaps mm can be difficult Joe: Can't verify, but it's consistent across devices and settings Would points or density-independent pixels be more helpful to developement teams then using mm? quintinb: Users can define what they want the physical size to be, the separation is intentional julian: Should we just follow the platform guidelines? Fingertips are variable in size and not precise. Shouldn't we be advocating for large touch targets? Rachele: Shouldn't we just reference the AAA requirement? Joe confirms JJ: (AA) Spacing can be 24 from another target and then size can be anything Sorry that was a reference to WCAG_AA not AA the user As an observation - we tried previously pushing Apple and Android sizes to our teams and got so much pushback from designers about it being too big. I will make sure to add my name as AAK, to avoid confusion quintinb ty AAK quintinb: we also need to be considerate that Google does allow for 32x32dp in seemingly certain cases JJ: Relying on public documentation can be problematic as the internal algo doesn't necessarily follow the 48x48 rule https://github.com/google/Accessibility-Test-Framework-for-Android/blob/c65cab02b2a845c29c3da100d6adefd345a144e3/src/main/java/com/google/android/apps/common/testing/accessibility/framework/checks/TouchTargetSizeCheck.java#L164 JJ: We may have to figure out what Google's math is - maybe someone can look later JJ A lot of people asking how to check size quintinb: ADB can be used to extract the ally tree and the density, which can calculate the dp size A physical ruler or sending screenshots and using likes of photoshop. Neither massively accurate but have struggled to find other methods when not having access to code in audits. JJ: but we need to be understanding of what tools auditors need Joe: Uses the scanner with larger requirements because it reports the details of what is wrong That's clever Joe_Humbert agree - thanks Joe - I think I failed to understand previously Mick has done an audit against 2.2 They have been sending screenshots and measuring with a ruler

1. Pixel Conversion:

• Joe: Highlighted the importance of CSS pixel alignment, emphasizing its native density for the platform.
• JJ: Proposed aligning with WCAG2ICT standards, which received agreement from the group.

2. Unit Considerations:

• Mick: Raised a question regarding the equivalence of 24 pixels to other platform units, suggesting using points or density-independent pixels for consistency. Also mentioned previous resistance from designers to larger sizes.

3. Advocacy for Large Touch Targets:

• julian: Advocated for following platform guidelines and emphasized advocating for larger touch targets for better accessibility.
• Mick: Highlighted the pushback faced from design teams regarding the implementation of larger sizes.

4. Accessibility Compliance Checks:

• quintinb: Suggested using ADB for extracting ally tree and density, while Joe recommended using a scanner tool for detailed reports on accessibility issues.

5. Tools and Techniques for Audits:

• Mick: Shared methods used for audits, including using physical rulers and screenshots for measurements.

[illai]

We probably can not refer this success criteria without taking into consideration it's conflict with both iOS and Android's accessibility guidelines. https://developer.apple.com/design/human-interface-guidelines/accessibility#Buttons-and-controls https://developer.android.com/guide/topics/ui/accessibility/apps#large-controls

This success criterion is very tricky when adjusting it from web to mobile. It allegedly touches on the same problem but refers to almost opposite concerns. On the web, the concern is that users will be able to hit the element easily with the mouse pointer, which is relatively small, and the real estate on the laptops and desktop screens is relatively spacious, while on mobile, the input pointer is the human finger and the mobile screens real estate is smaller. For that reason, I think this is an example of a success criterion in which we must adjust its content to fit mobile devices; otherwise (at least in my opinion), we miss the goal of creating guidelines that will suit the essentials of mobile technologies.

[AlainVagner]

A few interesting stuff I have found reading closed issues on the WCAG repository about 2.5.8:

• we need to keep in mind the different purposes of 2.5.8 (AA) and 2.5.5 (AAA): "with 2.5.8 the aim is to prevent mistaken clicks/taps, but with 2.5.5 the aim is correct click/taps."
• the value of 24px is coming from a compromise between what could benefit the users and the reality of websites with not exclusively touch interfaces (source)
• about the differences between pt, dp, and css pixels: "For all intents and purposes, when evaluating native apps on Android/iOS, you basically just read "CSS px" as meaning dp for Android, point for iOS"

[jha11y]

Notes from 25 September, 2024 Meeting:

[Meeting Minutes 25 September](https://www.w3.org/2024/09/25-matf-minutes.html#t03) quintinb: I think this is actually large considering there's no "unit standard" - Illai's MCAG does a great job at that Jamie: +1 Illai Illai: Both Android and iOS recommended sizes conflict with web - adopting 24x24 isn't sufficient Google also has different sizes based on where elements exist on the screen: https://github.com/google/Accessibility-Test-Framework-for-Android/blob/c65cab02b2a845c29c3da100d6adefd345a144e3/src/main/java/com/google/android/apps/common/testing/accessibility/framework/checks/TouchTargetSizeCheck.java#L161 Joe_Humbert: we could add a strongly worded note that 24x24 is too small practically for human fingers quintinb: How does this apply to links in mobile? (Just a point of interest ask) Jamie: 1. in testing context, folks don't have access to the exact numbers (@Joe has a solution - Google Ally scanner (Quintin adds the Android Debug Bridge 'uiautomator dump')) 2. In practice this is most an exception because of spacing https://m2.material.io/design/layout/pixel-density.html#pixel-density-on-the-web "When designing for the web, replace dp with px (for pixel)." Joe_Humbert: we could refer to the bounding box for the hit target size quintinb: +1 Joe_Humbert Illai: +1 Joe_Humbert ACTION: Add a note to 2.5.8 about a larger sizing requirement looking at the AAA requirement

[jamieherrera]

Pretty much @AlainVagner I'd agree on those points. Do you agree as well or have a different thought? The 2.5.8 exceptions exempt most scenarios for testing.

[jamieherrera]

@JJdeGroot could we maybe come back to this SC after some of the more well-worn A and AA SC have been discussed so that we can get through most SC in 2024?

This SC would need some additional documentation that differs from the "Understanding 2.5.8" documentation, for mobile apps, though I guess that could be a later version

[AlainVagner]

@jamieherrera yes I do :) Just wondering if we add a note on 2.5.8 promoting a bigger touch target size on mobile, like 44 css px (or pt or dp), maybe we should also consider what would be the enhanced version of this SC, as there will probably be some impact on 2.5.5.