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.

[julianmka]

Proposed note to address how small this SC would allow touch targets to be:

Twenty-four pixels is very small for targets on touch-based mobile devices. It is recommended that app makers use Success Criterion 2.5.5 Target Size (Enhanced) instead, making target sizes at least 44x44 pixels/DP/points.

Thoughts?

[JJdeGroot]

Discussed in yesterday's meeting.

9 October 2024

[Source](https://www.w3.org/2024/10/09-matf-minutes.html#d54b) ~~~text JJ: first discussion was 1 May 2024 JJ shares Issue from GitHub JJ: Apple and Android have requirement for larger touch targets JJ: explaining spacing exception in 2.5.8 JJ: continue discussion? Detlev: go beyond WCAG (target size)? JJ: stay in line with WCAG2ICT but some notes for best practices could be added JJ: such as recommending larger sizes, reference developer documentation JJ: Question was whether we better align with WCAG or WCAG2ICT -- the latter was preferred Julian: Tell people to choose whatever is the more accessible (eg. decide between WCAG requirement and Android/iOS recommendations). … Android and iOS are closed platforms where WCAG has no clout - that'S why we could instruct user sdto chosse the better one JJ: could be trouble to link directly to Apple and Google Joe: we should not use could language to inform people what they *should* be doing … could is not used … we could say it is too small for touch and one could point to triple A guideline without spacing exception Jamie: as to adding Apple and Google resources: WCAG resources do include references to these … "for information purposes only" … not endorsed, but available - we could do it as well … we are talking about AA 2.5.8 - we can point to AAA as best practice - should not linger longer, this is the AA standard JJ: most people felt it can be applied 'as is' JJ: comfortable with accepting as such and add a note to preferability of larger sizes? Add note to 2.5.8 to point people towards resources which recommend larger touch target sizes (such as WCAG 2.5.5, Apple, Google)? +1 +1 +1 +1 a+ +1 +1 +1 +1 Jamie: We would not be using the term CSS-pixels - replace with something else JJ: may be density pixels or other units that make sense ACTION: Add note to 2.5.8 to point people towards resources which recommend larger touch target sizes (such as WCAG 2.5.5, Apple, Google) ACTION: Replace CSS Pixel unit with appropriate unit on mobile such as Density Pixel JJ: will set up draft version of what guidance would look like ~~~

ACTION: Add note to 2.5.8 to point people towards resources which recommend larger touch target sizes (such as WCAG 2.5.5, Apple, Google)

ACTION: Replace CSS Pixel unit with appropriate unit on mobile such as Density Pixel

[JJdeGroot]

@julianmka

Proposed note to address how small this SC would allow touch targets to be:

Twenty-four pixels is very small for targets on touch-based mobile devices. It is recommended that app makers use Success Criterion 2.5.5 Target Size (Enhanced) instead, making target sizes at least 44x44 pixels/DP/points.

Thoughts?

To bring it a bit more in line with WCAG(2ICT) language:

Targets with a size of 24 by 24 points may be too small for users on touch-based mobile devices. It is recommended to follow Success Criterion 2.5.5 Target Size (Enhanced), which recommends that target sizes should be at least 44 by 44 points.

As WCAG2ICT does not include AAA requirements at this moment, we should link to WCAG instead?

Ideally we should link to our own interpretation of 2.5.8, but like WCAG2ICT, our first Group Note will only focus on A+AA.

[julianmka]

Much better, thanks @JJdeGroot! I agree that we should link to WCAG.

Once we have our own interpretation for 2.5.5, I wonder if we might even replace the guidance for this SC with something that amounts to "follow 2.5.8 because it's written with touch interfaces in mind." (Or perhaps a more strongly worded note?)

[JJdeGroot]

I think that might be changing the SC too much @julianmka

Also, 2.5.5 is missing the 'Spacing' exception which has some downsides for some common mobile interface design patterns.

[julianmka]

Good points. And we do know, of course, that Google and Apple don't always follow their own guidance for touch target size, which almost always comes up in conversations about this SC. Under 2.5.8, though, most of the instances where touch targets are smaller than 44x44 would pass.