W3C

Site Navigation

Nearby

Results of Questionnaire WCAG 2.2 - Target Size (min)

The results of this questionnaire are available to anybody.

This questionnaire was open from 2021-07-15 to 2022-05-17.

20 answers have been received.

Jump to results for question:

  1. Multiple overlapping elements interact oddly with offset #2159
  2. Use "area" in target spacing (minimum) #2162
  3. DONE: Name Change #1871
  4. DONE: Using "should" in the Understanding doc is confusing #1874
  5. DONE: Google feedback #1894
  6. DONE: Minimum Component Size #1870
  7. DONE: Adding diagrams that make the reality/consequences of target offset clearer #1848
  8. DEFUNCT: Target Size addition of user agent and equivalent exceptions #1993
  9. DONE: "the value of spacing" confusing wording #1852
  10. DONE: Adobe Comment #1889
  11. DEFUNCT: User-agent components that can't be styled #1904
  12. DONE: Further Examples Required #1872
  13. DONE: Align Target Size (min) with Target Size (enh) #1721
  14. DONE: Is "24 by 24 CSS pixels” reasonable? #1831
  15. DONE: Minimum Component Size #1870

1. Multiple overlapping elements interact oddly with offset #2159

Wilco raised issue 2159, which raised an odd cases where nested links can allow a large (but mostly covered) link to pass.

There was a long discussion, and it Wilco thought that a change would cause more problems/complexity than it solves.

A side discussion on nested links lead to PR 2330, which adds a little to the target-offset definition. The intent of the update is to exclude other links from the A to B measure.

Should we:

Summary

ChoiceAll responders
Results
Agree the response and update 5
Agree the response, reject the update (not change) 2
Agree with adjustment
Something else

(13 responses didn't contain an answer to this question)

Details

Responder Multiple overlapping elements interact oddly with offset #2159Comments
Aimee Ubbink
Abi James
Gregg Vanderheiden
Oliver Keim
Rain Breaw Michaels
Patrick Lauke
David MacDonald
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer
Andrew Somers
Laura Carlson Agree the response and update
Wilco Fiers Agree the response, reject the update (not change) > Targets other than A and B do not contribute to the spacing.

This doesn't make sense to me. When you have two points and take the distance between them, what does it mean that other targets don't contribute to the spacing? I don't understand the mathematics that are implied by that phrase.

I like the addition of the "(A)" and "(B)", but don't include that sentence.
Todd Libby Agree the response, reject the update (not change)
Stefan Schnabel Agree the response and update
Jaunita George Agree the response and update
Michael Gower Agree the response and update
Bruce Bailey Agree the response and update
Gundula Niemann "The offset from A to B may be different than the offset from B to A, if the size of these targets differs."
I feel it should say "if the sizes of these targets differ."

I feel the wording is overly complicated and triggers fantasy to trick.
Yet I won't die on this hill.

2. Use "area" in target spacing (minimum) #2162

Wilco raised issue 2162 pointing out an issue with the update text.

In summary, the new wording says is that anything that's more than 24 x 24px passes. The intent is that the default case is that for each target, you can draw a 24x24 square that is exclusively part of that target.

PR 2331 implements that change.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 6
Agree with adjustment
Something else 3

(11 responses didn't contain an answer to this question)

Details

Responder Use "area" in target spacing (minimum) #2162 Comments
Aimee Ubbink
Abi James
Gregg Vanderheiden
Oliver Keim
Rain Breaw Michaels
Patrick Lauke
David MacDonald
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer
Andrew Somers Something else On the one hand IMO the language "...have an area of at least 24 by 24 CSS pixels..." is better, though on the other hand, "an area of" means that 12px x 48px is equivalent, as it has the same area as 24 x 24. (576) a 27px diameter circle also has the same area, but would not cover the corners of the square.

But I have a question: where is this coming from? And why is touch-targets begin conflated with mouse-pointer targets?

The general consensus for finger-touch targets is a physical area of 7.5mm square to 9.2mm square, In terms of CSS px, this is between about 48px² to 60px² ... but that's for a finger touch on a phone, which is a very high ppi, and the finger occludes the touch area while touching, which is a principal reason it needs to be so large.

These same parameters do not apply to mouse-cursor/pointer targets, which are more likely on much lower density screens, and importantly, the finger is not occluding the target in this use case.

APPLE which has done substantial research here recommends a 60px x 60px finger touch area (Microsoft says 48px x 48px for finger touch).

But the mouse pointer targets in MacOS are very different, on the order of 12px x 12px (20px spacing) to 16px to 20px square — and spacing almost none for closely related controls to much more, depending on context. Example, main menu bar. The Apple logo is only 12px x 16px, but the non-visible target area is 35px x 22px. Menu items are 12px, with 19px spacing—but they are also wide, click once to open, and then the mouse can be dragged over to select the menu item with hover feedback, before clicking to select.


So, the WCAG definition of pointer including both finger-touch and mouse-cursor together is inappropriate as they both have separate and uniquely different user needs.

2.5.5 already covers touch-targets, at 44px² which is actually a little small compared to manufacturer recommendations.

In THIS SC, (2.5.8) 24px² does not serve a finger-touch interface well, and is more than common user interface targets in mouse-cursor oriented applications.

This indicates a few things:

1) The need for SCs to distinctly define touch vs mouse use cases, and apply appropriately therein.

2) If a site provides a version for touch interfaces, and a version for mouse interfaces, they should not be required to apply touch standards to those of mouse-oriented targets.

3) This is another area where user personalization is more important than an arbitrary standard that's going to get codified into law (because it's AA). It's easy to zoom a desktop/lap top. But a mobile touch interface is arguably much harder to zoom, and there the target size needs to be larger.


IN SHORT, this SC is not serving mobile nor desktop well.



Laura Carlson Agree with the update
Wilco Fiers Agree with the update
Todd Libby Agree with the update
Stefan Schnabel Agree with the update
Jaunita George Agree with the update
Michael Gower Something else My concern with the rewording is that it would now seem to allow a 2px by 238px target (which achieves an area of 24x24), which is what I think the rewording was designed precisely to avoid.

I think that an additive change may be better, but I was unable to come up with one in time for today's call.
IMO, the exisitng wording is actually less problematic than the produced change. The only unintentional pass I've seen is so close to 24x24 as to be neglibigle. I recommend sticking with:
<p>The size of the <a>target</a> for <a>pointer inputs</a> is at least 24 by 24 CSS pixels, except where:</p>


Bruce Bailey Agree with the update
Gundula Niemann Something else following Mike Gower I also think that referring to an area might allow very rectangle targets where one edge is quite small.

3. DONE: Name Change #1871

Ben and TPGi request in issue 1871 that the name be changed back to "pointer target spacing".

David provided a response, do you:

Summary

ChoiceAll responders
Results
Agree with the response 11
Agree with adjustment 2
Something else 1

(6 responses didn't contain an answer to this question)

Details

Responder DONE: Name Change #1871Comments
Aimee Ubbink
Abi James Agree with adjustment I agree with the response and this highlights the points I made in response to Q5 in that the understanding documents reads that spacing is as important and target size which this response is confirming is not the case.
Gregg Vanderheiden Agree with the response
Oliver Keim
Rain Breaw Michaels Agree with the response
Patrick Lauke Something else I can understand where Ben is coming from. My personal preference would also be to make the SC more clearly "Target Size/Spacing" or similar. But knowing the lengthy back and forth this SC already went through, I'm neutral on it...
David MacDonald Agree with the response
Jonathan Avila Agree with the response
John Foliot Agree with the response
Sarah Horton Agree with the response
Detlev Fischer Agree with the response
Andrew Somers
Laura Carlson Agree with the response
Wilco Fiers Agree with the response
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with adjustment As per the last survey item, I think it would benefit to make it clear that the SC was reswizzled so that the emphasis IS on Target Size. Spacing is just an exception bullet now.
Bruce Bailey Agree with the response
Gundula Niemann Agree with the response A big THANK YOU to the cognitive community for the quick memory aids for the SC numbers and text.

4. DONE: Using "should" in the Understanding doc is confusing #1874

Ben idenified some use of RFC should/must language in the target size understanding document in Issue 1874.

David created PR 2021 to re-phrase the language. Do you:

Summary

ChoiceAll responders
Results
Agree with the change 11
Agree with adjustment 2
Something else

(7 responses didn't contain an answer to this question)

Details

Responder DONE: Using "should" in the Understanding doc is confusing #1874Comments
Aimee Ubbink
Abi James Agree with the change
Gregg Vanderheiden Agree with the change
Oliver Keim
Rain Breaw Michaels Agree with the change
Patrick Lauke Agree with the change
David MacDonald Agree with the change
Jonathan Avila Agree with the change
John Foliot Agree with adjustment Suggested alternatives, but we can go either way:

"...larger viewport but it is preferred that the mechanism or link..."
or
"...larger viewport but it is suggested that the mechanism or link..."
or
"...larger viewport but it is recommended that the mechanism or link..."
Sarah Horton Agree with the change
Detlev Fischer Agree with the change
Andrew Somers
Laura Carlson Agree with adjustment
Wilco Fiers Agree with the change
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the change
Bruce Bailey Agree with the change
Gundula Niemann

5. DONE: Google feedback #1894

Dahlia from Google raised issue 1894 with various issues in a document.

Michael Gower created PR 2122 to tackle the editorial updates, and a response.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates and response 6
Agree with adjustment 2
Something else

(12 responses didn't contain an answer to this question)

Details

Responder DONE: Google feedback #1894Comments
Aimee Ubbink
Abi James
Gregg Vanderheiden
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the updates and response
David MacDonald Agree with adjustment Friendly amendments to soften the tone and remove "I" and "my" and other 1st person references and incorporate a bit of #1831:
============

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.
Jonathan Avila
John Foliot Agree with the updates and response
Sarah Horton Agree with the updates and response
Detlev Fischer Agree with the updates and response
Andrew Somers
Laura Carlson Agree with the updates and response
Wilco Fiers Agree with the updates and response
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with adjustment I saw David's responses. I have gone back and adjusted my responses in the Google doc to not use the first person and to match his modifications in language. If he wants to adjust his preamble, I am fine deleting my draft and letting his stand as the response.
Bruce Bailey
Gundula Niemann

6. DONE: Minimum Component Size #1870

Ben raised issue 1870 requesting that a minimum size (regardless of spacing) is added.

David created a proposed response.

Do you:

Summary

ChoiceAll responders
Results
Agree with the response 8
Agree with adjustment
Something else

(12 responses didn't contain an answer to this question)

Details

Responder DONE: Minimum Component Size #1870Comments
Aimee Ubbink
Abi James
Gregg Vanderheiden
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the response
David MacDonald Agree with the response
Jonathan Avila
John Foliot Agree with the response
Sarah Horton Agree with the response
Detlev Fischer Agree with the response
Andrew Somers
Laura Carlson Agree with the response
Wilco Fiers Agree with the response
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the response This is already closed.
Bruce Bailey
Gundula Niemann

7. DONE: Adding diagrams that make the reality/consequences of target offset clearer #1848

Patrick raised issue 1848, requesting examples are added to the understanding doc which outline what happens at smaller sizes.

Todd added the examples in PR 2108.

Do you:

Summary

ChoiceAll responders
Results
Agree with the updates 7
Agree with adjustment 1
Something else

(12 responses didn't contain an answer to this question)

Details

Responder DONE: Adding diagrams that make the reality/consequences of target offset clearer #1848Comments
Aimee Ubbink
Abi James
Gregg Vanderheiden
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the updates
David MacDonald Agree with the updates Note: Didn't review the pictures which are only referenced in the PR. Is there somewhere to see them?
Jonathan Avila
John Foliot Agree with the updates
Sarah Horton Agree with the updates
Detlev Fischer
Andrew Somers
Laura Carlson Agree with the updates
Wilco Fiers Agree with the updates
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with adjustment I wasn't able to figure out how to display the resulting page with images, but am assuming they are the ones shown in the issue. I like them!

I think some of the information in the ALTs could be worked into the figcaptions, making it easier for some sighted users and all users who cannot see them sufficiently to more easily understand.

For example
alt="Illustration showing four buttons abutting each other in a row. Another row shows the same buttons, now reduced in size with spacing on all sides of each button." />
<figcaption>The Play, Previous, Next and Settings targets are 24 by 24 pixels and can be arranged closely together. Reducing the target size to 10 by 10 pixels requires spacing/clearance of 14 pixels around each target to achieve the target spacing requirements, meaning that the overall space occupied by the four targets is bigger.</figcaption>
</figure>

I realize that existing image ALTs are not part of this change, but I do think the same approach could be considered there. Where the fig caption provides details, those details can be left out of the ALT, as long as the ALTs allow users to understand which images they are looking at in context of the page.

I wondered about the text on line 103 "...the smaller the actual target is". I think that is potentially not true, and even if true just adds some mental complexity unnecessary to clarity. When in doubt, take it out.
Bruce Bailey
Gundula Niemann Agree with the updates

8. DEFUNCT: Target Size addition of user agent and equivalent exceptions #1993

In PR 1993 Michael Gower updates the user-agent exception aspects.

These changes are intended to tackle issues 1976 and 1904.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 8
Agree with the update with adjustment
Something else 2

(10 responses didn't contain an answer to this question)

Details

Responder DEFUNCT: Target Size addition of user agent and equivalent exceptions #1993 Comments
Aimee Ubbink
Abi James Agree with the update
Gregg Vanderheiden Something else I worry about this new exception
<li><strong>Equivalent:</strong> The function can be achieved through a different control that has an area of at least 24 by 24 CSS pixels.</li>
What if the other control is three 'pages' down the page - or in the footer?
how would a person know of the existence of this alternate control - or where it could be found?
(no suggested solution except to EITHER - not allow the exception or to add "and the alternate control or a link to it can be seen next to the control" or some such. (don't like that -- just trying to think of something besides don't allow)
Oliver Keim
Rain Breaw Michaels Agree with the update
Patrick Lauke Agree with the update
David MacDonald
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer Agree with the update
Andrew Somers
Laura Carlson Agree with the update
Wilco Fiers Something else 1. "not modified by the author" is very vague. We made this mistake in WCAG 2.1, let's not make the problem any bigger. I have yet to find someone who can tell me what this really means. If I adjust the default font-size of the page, did I inadvertently change the size of all my components, so now I'm responsible? How does this work with components that adjust based on its content (which is just about everything). Am I responsible, if the user agent just wraps around whatever I put in? Because if not, this exception doesn't work for select elements, where authors control the width by how much text they put in.

2. I think it is very reasonable for content authors to be responsible for spacing between components. If some author stacks three checkboxes on top of each other, we might want to exempt them from adjusting the size, but surely they're responsible for not putting in whitespace.


I feel this SC needs to be written in a way that it can be tested programatically. Introducing this is going to make that a lot more problematic.
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the update
Bruce Bailey Agree with the update
Gundula Niemann Agree with the update

9. DONE: "the value of spacing" confusing wording #1852

Patrick raised Issue 1852 about a relative recent change in the understanding doc.

He also provide an update to resolve the confusion in PR 1853.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 8
Agree with the update with adjustment
Something else

(12 responses didn't contain an answer to this question)

Details

Responder DONE: "the value of spacing" confusing wording #1852Comments
Aimee Ubbink Agree with the update
Abi James
Gregg Vanderheiden Agree with the update
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the update
David MacDonald
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer
Andrew Somers
Laura Carlson Agree with the update
Wilco Fiers Agree with the update
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the update
Bruce Bailey Agree with the update
Gundula Niemann Agree with the update

10. DONE: Adobe Comment #1889

Andrew raised issue 1889 about legal forms based on paper version.

Detlev created PR 1955 to expand the exception.

However, it is possible that the group decides not to update the text, for which this proposed response would be used.

Do you:

Summary

ChoiceAll responders
Results
Agree with the change (adding the exception) 7
Agree with the change with adjustment
Agree with the response (NOT adding the exception) 2
Something else

(11 responses didn't contain an answer to this question)

Details

Responder DONE: Adobe Comment #1889Comments
Aimee Ubbink Agree with the change (adding the exception)
Abi James
Gregg Vanderheiden Agree with the change (adding the exception)
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the change (adding the exception)
David MacDonald
Jonathan Avila Agree with the response (NOT adding the exception)
John Foliot
Sarah Horton
Detlev Fischer
Andrew Somers
Laura Carlson Agree with the change (adding the exception)
Wilco Fiers Agree with the change (adding the exception)
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the response (NOT adding the exception) It seems to me that a legal requirement fits inside the existing "a particular presentation" wording of the exception
Bruce Bailey Agree with the change (adding the exception)
Gundula Niemann Agree with the change (adding the exception)

11. DEFUNCT: User-agent components that can't be styled #1904

James Catt raised issue 1904 about elements which could not be re-sized to meet the SC.

Detlev created PR 1956 to expand the exception to cover that scenario.

Do you:

Summary

ChoiceAll responders
Results
Agree with the update 7
Agree with the update with adjustment 1
Something else 1

(11 responses didn't contain an answer to this question)

Details

Responder DEFUNCT: User-agent components that can't be styled #1904Comments
Aimee Ubbink Agree with the update
Abi James
Gregg Vanderheiden Agree with the update
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the update
David MacDonald
Jonathan Avila Agree with the update
John Foliot
Sarah Horton
Detlev Fischer
Andrew Somers
Laura Carlson Agree with the update
Wilco Fiers Agree with the update
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Something else I'm concerned by this, as this SC is not just about size but about spacing. I'd at the least like that considered a bit more in how the exception is phrased. On first encountering this, I'm inclined to want to go with Patrick's wording about the author not being able to adjust, but I also appreciate the balancing act. Has anyone identified exactly which user agent implementations of which elements fail this SC out of the box?
Bruce Bailey Agree with the update
Gundula Niemann Agree with the update with adjustment It still says "If authors cannot style a native control so that".
Following the decision made, it should say "If authors did not style a native control so that" or "If authors did not style a native control, specifically if they cannot style it, so that"

12. DONE: Further Examples Required #1872

Ben asked in Issue 1872 for us to add further examples.

Detlev created PR 2024, and a response.

Summary

ChoiceAll responders
Results
Agree with the update and response 9
Agree with adjustment 2
Something else

(9 responses didn't contain an answer to this question)

Details

Responder DONE: Further Examples Required #1872Comments
Aimee Ubbink
Abi James Agree with the update and response
Gregg Vanderheiden Agree with the update and response
Oliver Keim
Rain Breaw Michaels Agree with the update and response
Patrick Lauke Agree with the update and response
David MacDonald Agree with the update and response
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer Agree with the update and response
Andrew Somers
Laura Carlson Agree with the update and response
Wilco Fiers Agree with adjustment I"m fairly reluctant to say this SC doesn't apply to partially obscured component. I would prefer we keep this a little vaguer, saying "targets while they are obsured" (remove "fully or partially").

I think it's a little more nuanced. If something's obscured, it simply isn't a "target". We have that covered.

Partially obscured is a little more tricky. I think if something is partially obscured, but can be scrolled fully into view, that's fine. If it can't be scrolled fully into view, that's effectively no different from having a smaller target, and so that's an issue. I don't know if the nuance of that needs to be in the understanding document. Seems fairly intuitive to me, but I wouldn't mind it getting added.
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with adjustment I think the final added paragraph may make more sense to appear under Benefits?
> >While the Success Criterion primarily helps touch users by providing target sizing to prevent accidental triggering of adjacent targets, it is also useful for mouse or pen users. It reduces the chances of erroneous activation due to either a tremor or reduced precision, whether because of reduced fine motor control or input imprecision.</p>
Bruce Bailey Agree with the update and response
Gundula Niemann Agree with the update and response

13. DONE: Align Target Size (min) with Target Size (enh) #1721

Wilco and Patrick raised issues 1721 and 1832 about the first line of the new Target Size SC not aligning with the one in WCAG 2.1.

PR 2082 was created to make that change.

Do you:

Summary

ChoiceAll responders
Results
Agree with the change 11
Agree with the change with adjustment
Something else 1

(8 responses didn't contain an answer to this question)

Details

Responder DONE: Align Target Size (min) with Target Size (enh) #1721 Comments
Aimee Ubbink
Abi James Agree with the change
Gregg Vanderheiden Agree with the change
Oliver Keim Something else The guidelines focus on web, as subsequent sentences expose by reducing the scope to web content for various devices.
The introduction sentence may consistently use this reduction of scope.
Rain Breaw Michaels Agree with the change
Patrick Lauke Agree with the change
David MacDonald Agree with the change I can live with it...

Pointer inputs is more accurate (with its accompanying definition) but currently is not well understood by rank and file developers.
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer Agree with the change
Andrew Somers
Laura Carlson Agree with the change
Wilco Fiers Agree with the change
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the change
Bruce Bailey Agree with the change
Gundula Niemann Agree with the change

14. DONE: Is "24 by 24 CSS pixels” reasonable? #1831

Kazuhiko Tsuchiya asked in 1831 whether 24px was reasonable, i.e. should it be bigger.

Jen Strickland provided a response, do you:

Summary

ChoiceAll responders
Results
Agree with the response 7
Agree with adjustment 2
Something else 2

(9 responses didn't contain an answer to this question)

Details

Responder DONE: Is "24 by 24 CSS pixels” reasonable? #1831Comments
Aimee Ubbink
Abi James Agree with the response
Gregg Vanderheiden Agree with adjustment This answer implies that you need to have both 24px AND 24px offset
"The minimum target size to meet Level AA is 24x24 pixels and includes a target offset of at least 24 pixels, with noted exceptions. "

change it to read (change bracketed)
The minimum target size to meet Level AA is 24x24 pixels [with exceptions if there is an offset of at least 24 pixels, or other] noted exceptions.
Oliver Keim
Rain Breaw Michaels Something else I can live with what the group decides, but am concerned that, in practice, this will lead designers and developers to think that the smaller sizes are sufficient overall.
Patrick Lauke Agree with the response
David MacDonald Something else I think the 1st bullet of the proposed response could confuse then reader to think there is a requirement for a 24px target size AND 24 px of offset.

A friendly amendment to the response:
====
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.
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer Agree with adjustment I have doubts about writing "There are some interfaces where smaller sizes are appropriate and necessary, for example the toolbars at the top of certain editing interfaces", especially about the 'necessary'. There are certainly drawbacks of 24x24, if you then have to put elements in drop-downs or change your interface in other ways to conform, but it looks doable to me - and there could always be the customization option to "show all editing controls, but at smaller size". So I would suggest to remove that sentence. Otherwise it sounds as if we are asking something we know cannot be done in some cases.
Andrew Somers
Laura Carlson Agree with the response
Wilco Fiers Agree with the response
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with the response The issue opener had already accepted the informal responses in the issue, so this is just adding a nice ribbon on the resolution :)
Bruce Bailey Agree with the response
Gundula Niemann Agree with the response

15. DONE: Minimum Component Size #1870

Ben and TPGi asked whether 24px should be the min size, regardless of the spacing in issue 1870.

David provided a response, do you:

Summary

ChoiceAll responders
Results
Agree with the response 3
Agree with adjustment 4
Something else 1

(12 responses didn't contain an answer to this question)

Details

Responder DONE: Minimum Component Size #1870Comments
Aimee Ubbink
Abi James Something else I agree with the response as compromises are necessary to including this SC at AA but it highlights that the current SC text and understanding document implies that target spacing is as important as the size which should be considered as part of this issue. For example in the current understanding document explaining the exceptions, both points 2 and 3 discuss spacing of targets, not size. This indicates to readers that a target size smaller than 24px is acceptable if spacing is present even when it could be possible to increase the target size within the UI design.

Point 2 ends with "Authors can anticipate the relative position of these links and accommodate sufficient target spacing" which could be "...sufficient target size and spacing" to reinforce that 24px x 24px should be the minimum size.
Point 3 starts with "If the spacing of the targets is essential to the information being conveyed.." which would be more accurate if it stated "If the size or spacing of the targets is essential to the information being conveyed..."

I also disagree with statement in the understanding document that "Spacing, alone and in conjunction with size, can improve user experience" as this is not the case on touch screens, particularly for older users. Studies show that target size is the more important factor than spacing and that 24px target and smaller size will impact performance. Ji et al (2013, https://www.tandfonline.com/doi/full/10.1080/10447318.2012.729996) showed that there was a 8x increase in errors and 2x increase in task completion time when target size reduced from 30px to 18px and that difference was not altered by increased spacing (although performance was better).

Gregg Vanderheiden Agree with adjustment Agree to not change to require 24 PX be min regardless of spacing
also agree with response except last sentence seems to need a word or something. Not clear what it is saying.
"Because targets that are smaller that 24 px are going to affect all users."
this does not seem to flow from above.
Suggestion--- just drop the last sentence?
Oliver Keim
Rain Breaw Michaels
Patrick Lauke Agree with the response
David MacDonald
Jonathan Avila
John Foliot
Sarah Horton
Detlev Fischer Agree with adjustment I am not sure it is true to say 'smaller sizes affect all users' - those with vision impairment are negatively affected. So I would just remove that rationale and say, it was a way of measurement introduced to cover certain edge cases that created problems for mandating a fixed minimum size requirement. I believe this was the reason for the offset exception, but cannot remember what cases exactly led to this solution (Wilco might).
Andrew Somers
Laura Carlson Agree with adjustment
Wilco Fiers Agree with the response
Todd Libby
Stefan Schnabel
Jaunita George
Michael Gower Agree with adjustment Having reviewed the original TPGi blog entry, I think it's worth pointing out in our response that the SC's emphasis is now on targets being 24x24
> Targets have an area of at least 24 by 24 CSS pixels, except where:

There is an exception where the target is less than 24x24 but allows sufficient space between targets to achieve effective 24x24 spacing. From a usage perspective, this does not increase the chance of accidental activation any more than 2 side-by-side 24x24 targets, which was one of the original concerns of TPGi

The understanding document also contains the following information, which I also think addresses a concern expressed in the original document:
> Touchscreen devices and user agents generally have internal heuristics to identify which link or control is closest to a user's touch interaction - this means that sufficient spacing around a target can work as effectively as a larger target size itself.
Bruce Bailey Agree with the response
Gundula Niemann

More details on responses

  • Aimee Ubbink: last responded on 19, July 2021 at 20:06 (UTC)
  • Abi James: last responded on 7, November 2021 at 14:07 (UTC)
  • Gregg Vanderheiden: last responded on 9, November 2021 at 16:07 (UTC)
  • Oliver Keim: last responded on 22, November 2021 at 13:20 (UTC)
  • Rain Breaw Michaels: last responded on 23, November 2021 at 00:14 (UTC)
  • Patrick Lauke: last responded on 29, November 2021 at 08:59 (UTC)
  • David MacDonald: last responded on 29, November 2021 at 10:11 (UTC)
  • Jonathan Avila: last responded on 30, November 2021 at 12:05 (UTC)
  • John Foliot: last responded on 30, November 2021 at 12:50 (UTC)
  • Sarah Horton: last responded on 30, November 2021 at 15:29 (UTC)
  • Detlev Fischer: last responded on 2, December 2021 at 21:05 (UTC)
  • Andrew Somers: last responded on 29, April 2022 at 02:49 (UTC)
  • Laura Carlson: last responded on 29, April 2022 at 14:15 (UTC)
  • Wilco Fiers: last responded on 3, May 2022 at 10:39 (UTC)
  • Todd Libby: last responded on 3, May 2022 at 14:28 (UTC)
  • Stefan Schnabel: last responded on 9, May 2022 at 12:27 (UTC)
  • Jaunita George: last responded on 9, May 2022 at 22:21 (UTC)
  • Michael Gower: last responded on 10, May 2022 at 14:59 (UTC)
  • Bruce Bailey: last responded on 16, May 2022 at 19:54 (UTC)
  • Gundula Niemann: last responded on 17, May 2022 at 15:44 (UTC)

Non-responders

The following persons have not answered the questionnaire:

  1. Chris Wilson
  2. Lisa Seeman-Horwitz
  3. Janina Sajka
  4. Shawn Lawton Henry
  5. Katie Haritos-Shea
  6. Shadi Abou-Zahra
  7. Chus Garcia
  8. Steve Faulkner
  9. Gez Lemon
  10. Makoto Ueki
  11. Peter Korn
  12. Preety Kumar
  13. Georgios Grigoriadis
  14. Romain Deltour
  15. Chris Blouch
  16. Jedi Lin
  17. Jeanne F Spellman
  18. Kimberly Patch
  19. Glenda Sims
  20. Ian Pouncey
  21. Alastair Campbell
  22. Léonie Watson
  23. David Sloan
  24. Mary Jo Mueller
  25. Peter Heery
  26. John Kirkwood
  27. Reinaldo Ferraz
  28. Matt Garrish
  29. Mike Gifford
  30. Loïc Martínez Normand
  31. Mike Pluke
  32. Jon Gibbins
  33. Justine Pascalides
  34. Chris Loiselle
  35. Tzviya Siegman
  36. Jan McSorley
  37. Sailesh Panchang
  38. Cristina Mussinelli
  39. John Rochford
  40. Sujasree Kurapati
  41. Jatin Vaishnav
  42. Sam Ogami
  43. Kevin White
  44. E.A. Draffan
  45. Paul Bohman
  46. JaEun Jemma Ku
  47. 骅 杨
  48. Victoria Clark
  49. Avneesh Singh
  50. Mitchell Evan
  51. biao liu
  52. Scott McCormack
  53. Rachael Bradley Montgomery
  54. Francis Storr
  55. David Swallow
  56. Aparna Pasi
  57. Gregorio Pellegrino
  58. Melanie Philipp
  59. Jake Abma
  60. Nicole Windmann
  61. Ruoxi Ran
  62. Wendy Reid
  63. Scott O'Hara
  64. Charles Adams
  65. Muhammad Saleem
  66. Amani Ali
  67. Trevor Bostic
  68. Jamie Herrera
  69. Shinya Takami
  70. Karen Herr
  71. Kathy Eng
  72. Cybele Sack
  73. Audrey Maniez
  74. Jennifer Delisi
  75. Arthur Soroken
  76. Daniel Bjorge
  77. Kai Recke
  78. David Fazio
  79. Daniel Montalvo
  80. Mario Chacón-Rivas
  81. Michael Gilbert
  82. Caryn Pagel
  83. Achraf Othman
  84. Helen Burge
  85. Fernanda Bonnin
  86. Christina Adams
  87. Raja Kushalnagar
  88. Jan Williams
  89. Isabel Holdsworth
  90. Julia Chen
  91. Marcos Franco Murillo
  92. Yutaka Suzuki
  93. Azlan Cuttilan
  94. Jennifer Strickland
  95. Joe Humbert
  96. Ben Tillyer
  97. Charu Pandhi
  98. Poornima Badhan Subramanian
  99. Alain Vagner
  100. Roberto Scano
  101. Kun Zhang
  102. Regina Sanchez
  103. Shawn Thompson
  104. Thomas Brunet
  105. Kenny Dunsin
  106. Jen Goulden
  107. Mike Beganyi
  108. Ronny Hendriks
  109. Rashmi Katakwar
  110. Julie Rawe
  111. Duff Johnson
  112. Laura Miller
  113. Will Creedle
  114. Shikha Nikhil Dwivedi
  115. Marie Csanady
  116. Meenakshi Das
  117. Perrin Anto
  118. Brian Elton
  119. Rachele DiTullio
  120. Jan Jaap de Groot
  121. Rebecca Monteleone
  122. Ian Kersey
  123. Peter Bossley
  124. Michael Keane
  125. Chiara De Martin
  126. Giacomo Petri
  127. Andrew Barakat
  128. Devanshu Chandra
  129. Xiao (Helen) Zhou
  130. Joe Lamyman
  131. Bryan Trogdon
  132. Mary Ann (MJ) Jawili
  133. 禹佳 陶
  134. 锦澄 王
  135. Stephen James
  136. Jay Mullen
  137. Thorsten Katzmann
  138. Tony Holland
  139. Kent Boucher
  140. Phil Day
  141. Julia Kim
  142. Michelle Lana
  143. David Williams
  144. Mikayla Thompson
  145. Catherine Droege
  146. James Edwards
  147. Eric Hind
  148. Quintin Balsdon
  149. Mario Batušić
  150. David Cox
  151. Sazzad Mahamud
  152. Katy Brickley
  153. Kimberly Sarabia
  154. Corey Hinshaw
  155. Ashley Firth
  156. Daniel Harper-Wain
  157. Kiara Stewart
  158. DJ Chase
  159. Suji Sreerama
  160. Fred Edora
  161. Lori Oakley
  162. David Middleton
  163. Alyssa Priddy
  164. Young Choi
  165. Nichole Bui
  166. Julie Romanowski
  167. Eloisa Guerrero
  168. George Kuan
  169. YAPING LIN
  170. Justin Wilson
  171. Leonard Beasley
  172. Tiffany Burtin
  173. Shane Dittmar
  174. Nayan Padrai
  175. Matt Argomaniz Matthew Argomaniz
  176. Frankie Wolf
  177. Kimberly McGee
  178. Ahson Rana
  179. Carolina Crespo
  180. humor927 humor927
  181. Jackie Fei
  182. Samantha McDaniel
  183. Matthäus Rojek
  184. Phong Tony Le
  185. Bram Janssens
  186. Graham Ritchie
  187. Aleksandar Cindrikj
  188. Jeroen Hulscher
  189. Alina Vayntrub
  190. Marco Sabidussi
  191. John Toles
  192. Jeanne Erickson Cooley
  193. Theo Hale
  194. Gert-Jan Vercauteren
  195. Karla Rubiano
  196. Aashutosh K
  197. Hidde de Vries
  198. Julian Kittelson-Aldred
  199. Roland Buss
  200. Aditya Surendranath
  201. Elizabeth Patrick
  202. Tj Squires
  203. Nat Tarnoff
  204. Illai Zeevi
  205. Filippo Zorzi
  206. Gleidson Ramos
  207. Mike Pedersen
  208. Rachael Yomtoob
  209. Oliver Habersetzer
  210. Moaan Ahmed
  211. Irfan Mukhtar
  212. Rachel White
  213. Sage Keriazes
  214. Tananda Darling
  215. Nina Krauß
  216. Demelza Feltham
  217. Ragvesh Sharma
  218. Shunguo Yan
  219. Nora GOUGANE
  220. Tim Gravemaker
  221. Roldon Brown
  222. qin guan
  223. Alexandra Yaneva
  224. Carrie Hall

Send an email to all the non-responders.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.