Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.5.8 Understanding origin of minimum "24" #4178

Open
jamieherrera opened this issue Dec 16, 2024 · 7 comments
Open

2.5.8 Understanding origin of minimum "24" #4178

jamieherrera opened this issue Dec 16, 2024 · 7 comments

Comments

@jamieherrera
Copy link

Apologies if this is a repeat from other 2.5.8 questions... I've looked at over 15 and can't find any with this question. If I missed it please add here and feel free to close as a repeat of that issue #.

2.5.5 Target Size (enhanced) explains that the 44 x number is a rough equivalent of the pad of a finger. Could you add a sentence about where the decision of 24 px came from for 2.5.8 Target Size (Minimum)? I may have seen in this forum or related blog from a W3C member that the number "24" came from the pixel size of the size of a (default size) mouse pointer. I can't find the source now and that may not be entirely accurate; i would rather quote the Understanding document for the origin for "24 px" (and not 16 or 22 or 28 ...).

As an aside, the Related Resources research appears to copy over the same research article as from 2.5.5. I only had access to the abstract; are there additional resources that could guide why the 24 px minimum was determined to be the number to use?

Thanks in advance.

@bruce-usab
Copy link
Contributor

@jamieherrera -- I was "in the room" when AGWG picked 24px but I cannot tell you the genesis. But why does that matter?
Are you having difficulty implementing or enforcing? Obviously, we wanted to go as large as we could while picking something feasible for all technologies all the time.

Thinking about in-line graphics, since those are common, 12pt is 16px and 24px is half-again larger. So that is about as large a target size could be without hitting the line above/below. 24px targets in a line of text is not unreasonable.

The Related Resources are the best we could find. Yes, many academic articles are behind a pay wall. I don't believe you will be able to find an authoritative citation for 24px over 16 or 22 or 28.

@bruce-usab
Copy link
Contributor

Discussed on Backlog call 1/10/25, Bruce to look through closed issued. Alastair recalls real-life examples setting size.

@gundulaniemann
Copy link
Contributor

According to my memory, there was a research showing tap accuracy for several target sizes (successfully triggering the intended element). a size of 24 CSS px ( 1/4 of an inch) yields an accuracy of 50% according to that paper.
It was brought up by a quite new member of the group at that time. She disappeared from the group some months later.
The research paper was shown during meetings, yet the link did not work in the sense that access was restricted.
I remember my disappointment I could not dive in and reflect on it.

@alastc
Copy link
Contributor

alastc commented Jan 10, 2025

As I couldn't find a previous issue (even though I'm sure this has come up before), I'll draft a response:


Going by the research there is a fairly large continuum of sizes that could be considered necessary for people with mobility impairments. Some of the research was suggesting 100px square as a minimum. The manufacturers have coalesced around a 44/48px (equivalent) sizing for their interface standards.

We started with using 44px as the minimum size, but there are quite a few interfaces with smaller targets that could not increase the size of target.

For example, we received issues from people with low-vision complaining that increasing the size of buttons on a WYSIWYG editor would reduce the number of buttons they have access to by default. With a zoomed in view, target size isn't the issue, screen-estate is.

Also, some interfaces on mobile have smaller targets and don't have the screen-estate to achieve a larger target area. E.g. The "back to previous app" button in the top-left of iOS, or the A-Z down the side of the contacts app.

The previous-app button has space around it (usually), and the A-Z acts as a slider where you can still scroll normally as well. These are not problematic in practice, so it should not be something that fails.

So feasibility reduced the size from 44px and we had to pick a size on a continuum. 24px allowed for most of the icon-button sizes used on popular sites and applications (e.g. Google Docs). If they can achieve that size, it must be feasible.

As is often the case, WCAG defines a baseline, a minimum, and we encourage people to use larger sizes.

@gundulaniemann
Copy link
Contributor

just some information which hopefully you find useful:

You wrote "The manufacturers have coalesced around a 44/48px (equivalent) sizing for their interface standards."
In fact, in many web articles the abbreviation 'px' is used meaning different measurements in different contexts.

Apple requests a size of 44 x 44 point which is equivalent to 25,91 CSS px,
and Google requests a size of 48x48dp which is equivalent to 28,8 CSS px,
and Microsoft recommends 32 epx as minimum which is equivalent to 22,68 CSS px as well as 40 epx as typical which is equivalent to 28,35 CSS px.

point (Apple, 1/163 of an inch),
dp (Google, 1/160 of an inch),
epx (Microsoft, "effective pixels", using 'epx', 'ep', and 'px' as equivalent, 40 epx represent 7,5mm).

I also found some links which you might find helpful:
https://github.com/w3c/wcag/pull/2108/files
#1894 (comment) (is this the conversation you were looking for?)

https://www.microsoft.com/en-us/research/wp-content/uploads/2006/01/parhi-mobileHCI06.pdf?ref=scotthurff.com
comes to the following conclusion:
"The results showed that while speed generally improved as targets grew, there were no significant differences in error rate between target sizes ≥ 9.6 mm in discrete tasks and targets ≥ 7.7 mm in serial tasks. Along with subjective ratings and the findings on hit response variability, we found that target size of 9.2 mm for discrete tasks and targets of 9.6 mm for serial tasks should be sufficiently large for one-handed thumb use on touchscreen-based handhelds without degrading performance and preference. "

https://learn.microsoft.com/en-us/windows/apps/design/input/guidelines-for-targeting
talks about 32x32 epx as minimum,
further down about 7.5mm square as typical.
They say "In general, set your touch target size to 7.5mm square range (40x40 pixels on a 135 PPI display at a 1.0x scaling plateau). " (they use the terms epx, ep, and px interchangeably)

At the end, this doesn't really change your rationale how we came to use 24 CSS px. We just did not go down as much as it seems, just by around 2 CSS px (if we start with the minimum among the requests mentioned above).

@patrickhlauke
Copy link
Member

patrickhlauke commented Jan 11, 2025

Apple requests a size of 44 x 44 point which is equivalent to 25,91 CSS px,
and Google requests a size of 48x48dp which is equivalent to 28,8 CSS px,
and Microsoft recommends 32 epx as minimum which is equivalent to 22,68 CSS px as well as 40 epx as typical which is equivalent > to 28,35 CSS px.

point (Apple, 1/163 of an inch),
dp (Google, 1/160 of an inch),
epx (Microsoft, "effective pixels", using 'epx', 'ep', and 'px' as equivalent, 40 epx represent 7,5mm).

curious about where you found those values...because purely looking at my iPhone SE (2nd edition) for instance, it reportedly has screen dimensions of 375 points by 667 points (per https://developer.apple.com/design/human-interface-guidelines/layout), and when I check a web page that tests web content viewport sizes, it tells me that the viewport is 375px by 553px (the missing pixels are for the browser chrome) ... so an Apple point is exactly the same as a CSS px

@bruce-usab
Copy link
Contributor

bruce-usab commented Jan 13, 2025

@jamieherrera -- I found a previous thorough response at end of closed issue 2704 -- @alastc I am not sure, is this one you were thinking of?

Regardless, my understanding is that we should leave this issue open for PR to add some of this detail to Understanding.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants