Difficulties with inconsistency of Target Size (Minimum) #2695
Comments
|
Could we calculate the size of the bounding box that have enough space (vertically and/or horizontally, but not diagonally) and if this is big enough, we pass otherwise we only look at the vertical or horizontal distance, never the diagonal and fail. In this case A and B would still both pass (but for different reasons) and C would still fail? |
|
Would you not need to just look at the shortest distance? Otherwise I'm sure you can find diagonal/odd combinations where there is indeed more than 24px offset in most cases, but what counts I thought is that this holds true for all points? |
|
@WilcoFiers It would help if you correct the names in your example, there is no Link A... |
|
I took the liberty to edit the first Link B (in OP) to Link A.
No. The need is to have spacing somewhere for the target distinct from nearby targets. That other distances are closer than that is not relevant. This is a good example to discuss, especially with regards to measuring the 24 px, but is not this specific example covered by the Inline exception? Is |
where does a list stop being a list? what if it's styled not to have bullets, and just button-like links? is it still a block of text based on the original underlying markup? |
|
I tried to rework the definition of offset to fix this issue. Here's what I've come up with:
While it's certainly more complex, I think this is going to feel more intuitive. I decided to move all the complexity into the note though. WCAG did a similar thing with luminance, which never seems to have bothered anyone. Doing it this way means we can keep the definition relatively clear. I worked out some new examples of this issue in the codepen that I've been keeping on target size (https://codepen.io/wilcofiers/full/abZxPow). The difference is in example P. In the current version P2 passes, and P3 fails only for the bottom target. With this update, P2 and P3 fail for both targets.
Long image descriptionTwo rows of test target examples. P1 through P4.
The top row of examples, using the current definition, show P1 and P2 pass, for P3 the small target fails, but the large target passes. P4 passes. The bottom row, using the updated definition shows P1 passing, and P2, P3 and P4 failing. |
|
It does seem to be a logical outcome of applying a 2D approach to the offset. It matches desirable behaviour (i.e. there is an area of sufficient size somewhere), but it doesn't appear intuitive in practice. I think someone (possibly me but not sure) suggested keeping it one-dimensional, i.e. separating horizontal and vertical. So the offset would only be measure horizontally, and vertically, not diagonally.
Otherwise I'm not sure how you'd assess something that isn't horizontally or diagonally aligned (like q1 above). You could have a 15px square that is right next to another one, just one pixel spacing to the up-left with no overlap. |
|
I thought we want buttons like P1 and P2 (and top button in P3) to be a pass? (Assuming the overhang is diagonally 24px.) The visualization I consider is a circle with diameter of 24px (which can be measured on the diagonal as needed). @WilcoFiers — I do not find your note easier to parse as compared to what we have. I like it even less if it is turning some near-passes to barely-fails. |
|
@bruce-usab The overhang is 18 pixels, not 24. But that's a good idea, best to have that as an example for P2/Q2. It makes the case more clearly. I do not think this update is easier to read. It isn't. But it's going to give more predictable and intuitive results. @alastc I remember we looked at just doing horizontal or vertical, but that left a lot of questions that were difficult to handle. In my code pen, everything except A, B, P and Q uses diagonal measures somewhere. Diagonals work really well in things that overlap, or partially overlap. We can possibly handle those cases without diagonals too, but it makes things a good deal more difficult. UPDATE: I adjusted P2 and Q2 so that the overhang is 24 pixels. In the definition I'm proposing, P2/Q2 would fail, even if the horizontal offset is 24 pixels, because the vertical offset is only 18 pixels. That's the problem this is trying to solve. Vertically stacked things shouldn't pass in unpredictable situations because of variability in width or line indentation.
|
I agree that FWIW the ICT Baseline (something of an analog to Trusted Tester) is wrestling with this and currently includes the concept of
I do not agree that P2/Q2 should fail. Is the target size and offset not sufficient (for what 2.5.8 is intended to address)? |
you miss my point, @bruce-usab ... my question is when one can or can't call something a "block of text" to get to the exemption. does the underlying markup count? or how it's presented? or ... and if it's the underlying markup, regardless of how it's visually displayed, then that's...probably going to lead to very arbitrary-looking passes/fails |
|
@patrickhlauke @bruce-usab Could one of you open a separate issue for the "block of text" question? We're starting to have 2 conversations in one issue. |
|
@patrickhlauke are you saying we should not have that exception or that it needs to be refined? Link C in OP is in a block of text. It is a bulleted list that visually presents as a block of text. It does not provide an accessible target size of 24 px. It passes 2.5.8 because of the inline exception. The SC has this loophole, but I think that is okay, and better than any alternative we have been able to draft. I do not think there is an issue on this particular point. @WilcoFiers I think we first have to agree if your P2/Q2 is a fail (or not). I thought your example at top was illustrating that it is tricky to measure the distances. It is a sidebar that tightly spaced text targets c 8000 an be problematic (but they get a pass, because of the exception) but equivalently sized image targets are correctly caught by the SC. |
Two observations from me:
|
|
From a conversation with Michael, we'd really struggle to make updates to the normative text at this stage. |
|
As to blocks of text: I think it would have to be visual appearance, since target size is all about the visual aspect, not underlying mark-up. So,
Is it messy? Yes. But I hope if we focus on the visual aspect and provide enough examples, it should be clear enough. (I kept the discussion here to avoid creating even more new issues...) |
|
BTW, I'm much happier with the P outcomes listed than the Q outcomes proposed in Wilco's comment. |
AGWG made normative changes to WCAG 2.1 between proposed rec and rec.
I'm really not so sure it works like this. Take this categories section on wikipedia for example. Can any of you tell if any of these fail the SC, and if so which ones?
|
Presumably such a list is text links, so they fall under the exception for User Agent Control. But for sake of argument, assuming ~16px buttons instead, I count ten targets spread over three rows. Only the single top right (Internet Standard organizations) and bottom right two (Web services, Tim Berners-Lee) meet 2.5.8 Target Size and so the page as a whole fails 2.5.8. |
|
I'm not sure I understand why it might satisfy the User Agent Control exception?
That's not what I get when I run the math. Only three of these actually fail the SC (it changes if the viewport width changes though).
Those are the only links in this where the offset is measured vertically. Everything else in that list has its offset measured on a diagonal, and so passes the SC. It's more or less a happy accident that there are three failing lists in this at all. This same section on other pages can pass completely, depending on the width of the different links. |
|
Is not the User Agent Control exception applicable to text links?
We agree that every pixel at the bottom of I am not seeing where diagonal measures are even relevant. The word "categories' is not hypertext, so I think you could find a 24x24 target that hits left part of |
|
Remember offset is measured from the farthest point on the target, to the closest point to the adjacent target. On something like the
Each line is an offset between the |
@WilcoFiers – none of those diagonal line are relevant and none match the definition of target offset. You're finding the farthest distance between targets when what is required is the closest distance. For example, starting at the |
|
I don't think the intent of Target Size was to focus on text links. The Genesis of this SC came out of the mobile TF, where they were addressing the size of buttons, etc. If there is any site in the world that seems like it's primarily a bunch (i.e blocks) of text, it's wikipedia. A lot of that text content is links. They are positioned wherever my browser width or whatever ends up placing them. In addition to the inline exception, which I think these are covered under, I'd like clarity on when someone thinks the user agent control exception ceases to apply to links. On the wikipedia page, text links for the most part seem sized and positioned by user agent. In fact in many cases the line spacing is being increased from the default by wikipedia (line-height 1.6). Is the argument that the shorter default line height is a pass, but the increased wikipedia line height is a fail? |
With all due respect @bruce-usab, I know how to read a definition. I largely wrote this one, so I should better know what it says. I spent months helping to write and test this SC and its definitions. Just because your understanding of this definition is different from mine, doesn't mean my understanding is wrong, or naive.
It sounds like what you're doing is to try and find a single "farthest point", from which offset is measured to every adjacent link. Is that correct? What my understanding is (and that was the intent when I proposed the definition) was for the farthest point to be different for different adjacent targets. The farthest point away from
I don't personally see this as a block of text. My intuition of "block of text" is that there needs to be text that isn't part of any link or other widget. We don't have a definition here though so everyone gets to invent their on heuristics for what is and isn't a block of text. There are a lot of similarities between this categories example and a long breadcrumbs list. An inline link list, with a separator between them. This isn't a rare pattern. As for the "modified by the author" exception, I raised this too when we discussed it. It's too vague for my taste. My understanding is that almost everything is modified by the author, because the author determines the size of content that the control fits around. There are little edge cases, like the browser's built in date picker that fall under this exception. But again, there's no definition. We're leaving a lot of things for ACT TF to figure out with this one. It certainly does seem like we have a significantly different understanding of these two exceptions. We need to do something about that. |
Yep, that's my recollection/understanding of the intent and the normative language as well. One is always measuring one target relevant to every other adjacent one, and we're always looking to confirm that there is 24 pixels between at least one pixel that triggers one target and a pixel that triggers another. It's in every direction, but the pixel you are assessing changes. (Otherwise two rows of 24x24 targets with no space between them would fail.)
I agree. And I'd consider those all links in blocks of text. Let's be clear, here. It's possible to make every link target meet this requirement on a web page. You'd increase the word spacing and line spacing to the point there is always 24 CSS pixels between multiple 1-character links (minus the minimum width and height of the actual character hit area). I'm assuming everyone can agree that while that might make them easier to hit, it would have such a profound effect on content understanding for many of us that it would be disastrous. So, the question becomes:
The answer potentially could be "when the link is given another UIC role". That's a programmatic response, but it's not bad. If I give the anchor a role of menu item, the spacing applies. If I give it a role of button, it applies. That means, I'd have to make sure my menu items' hit areas were at least 24 pixels across, and that vertically there was always 24 pixels from the bottom of the link's hit area to the bottom of the next (whether through text sizing, line height, padding or whatever). The challenge with this approach comes when some folks want a link that is being used as a menu item NOT be programmatically a menu item, but remain a link (probably also a list item) inside a disclosure pattern instead. So, you'd have the bizarre situation where two things that look identical and behave almost the same (depending on implementatino) would be assessed differently. I don't have an answer to this. I agree that it puts the SC at risk. |
No, that is not what I am doing. What counts as the "farthest point of a target (A)" depends on the "nearest point of the second target (B)" which, I am somewhat concerned, might make the definition recursive.
This comports with my understanding, and why I am confused by @WilcoFiers five colored lines, as I do not see how any of them are useful for evaluating pass/fail for the this SC.
I agere.
I agree. It has to be the case that any text link in sentence gets a pass (i.e., an exception applies). Yes, text links are frequently difficult to hit with a finger, and disproportionately problematic for PWD, but they are ubiquitous. I am okay with a horizontal list of hypertexted words, each a different link, each hard to hit by finger, and each getting a pass from this SC under the exception. The Wikipedia categories footer is a fine example of this. It is not a menu, just a list of links. It is not great UI, but it's not something that should be a fail at AA. I appreciate that this is a bit subjective, but I also have no problem failing a text-heavy vertical sidebar or horizontal menu against this SC. Does anyone have examples of sidebar/menus which fail but probably should not? Or sidebar/menus which pass but probably should not? |
|
@bruce-usab can you draw out how you would measure offset from the
Why would "farthest point on A" depend on "nearest point on B", or be recursive? The way I read the definition is like this. Step 1: Find the longest line you can draw between A and B. That's usually a corner to corner thing, but there are some edge cases. That give you which point on A is the farthest from B. Step 2: From that farthest point, find the shortest line you can draw that touches the edge of B. The length of that second line is the offset. Can you explain how you would do this math differently? |
Ok, so there is a gap where that measure doesn't catch something undesirable, but then Wilco's version does catch (fail) some things which are sufficient to hit (e.g. the top link of the 1st example in the 1st post). Considering:
That doesn't seem to improve the situation for the wikipedia categories links. If you only consider A & B, you can still position the radius away from particular links: I think it would need to be a circle not overlapping any other targets to solve that problem. |
I definitely agree that I would like to see these personas represented in the user research that I'd expect this SC to be based on.
I wouldn't characterize the important question as whether the person knows where they need to press on the button; I think the important question is where the person tends to press on the button, which might be based on a combination of knowledge, muscle memory, calibration of the input device, etc. In particular, I don't think it's safe to assume that any of the personas you've listed would actually tend to hit a spot on a button furthest from crowding just because they have experience with their disability. For example, the "Target Size Study for One-Handed Thumb Use on Small Touchscreen Devices" study linked from WCAG 2.1 SC 2.5.5's references included a test where users were asked to press within crowded 3x3 grids of buttons on a mobile device using their thumb. This figure from section 5.1 represents the exact registered hit locations (the individual dots) from those tests in relation to the buttons (the white squares).
According to the study, 90% of the participants "used keypad-based handhelds regularly", yet at the smallest target size, the bias in where they pressed on the buttons does not consistently correspond to selecting spots that are furthest from crowding with other buttons! The buttons on the right side of the grid do on the horizontal axis only, but at the smallest target size the vertical axis bias actually tends towards the crowded side of the button (ie, towards the bottom for the top row of buttons and towards the top for the bottom row of buttons). I think a broader version of this study which includes representation of the personas you've mentioned and a variety of input devices would be very valuable in guiding whether this requirement should be based on centers vs farthest-points. The study above is the closest I found, but it doesn't consider as broad a set of user personas as I'd like the SC to be based on, and I don't think its results justify a "furthest-point" algorithm even for the limited population/devices it did study. |
|
@alastc wrote:
Your green circle illustrates that red Target A is sufficiently spaced from green Target B — because A is much wider. Considering the targets in the other order, as one must, it is not possible to place a circle of the same diameter (i.e., center and radius within green Target B, towards A – but not overlapping red Target A).
If the SC results in failing Wilco's P2/Q2 & P3/Q3 that is better than passing P4/Q4 (because of a diagonal measure across the longer side). For targets in column, target offset could just be vertical size plus vertical spacing. For targets in row, target offset could just be horizonal size plus horizonal spacing. But I cannot think of a pithy way to specify which to use! One cannot just use the smaller of the two measures (since short wide targets all in a row are not problematic) nor the larger of the two (since short wide targets all in a column are problematic). Wilco's size of a target plus the spacing to the second target is the closest we have gotten (without using a circle) but the note explaining vertically/horizontally targets is quite long and not yet complete. (It still has the underspecified "farthest point of a target (A)" and does not describe"vertically aligned".) Here is my attempt to refine:
|
I just meant that without the definition saying that you cannot overlap other targets (C, D, E etc), the circle doesn't solve the diagonals problem. It would need to be something like: But I think that has problems, particularly because it is a circle and could overlap other targets quite easily, in ways that might not be problematic.
Could that be: In horizontally aligned targets the closest edge will have to be left/right, or a point on the left/right edge, otherwise they wouldn't be horizontally aligned. I think a couple of diagrams in the understand doc would avoid misunderstandings. Is that a reasonable thing to put to the group then? |
|
I agree with not pursuing using a circle for Spacing exception. But...
The circle approach does solve the diagonals problem, because it applies to any radius line in the circle. But I now think the horizontally/vertically aligned approach is better because it is more restrictive. @dbjorge raises the question above if the circle approach isn't being too tolerant with overhangs? Wilco's refinement (accounting for horizontally/vertically aligned targets) is close to the CR version (and using a circle instead, is not).
All versions of Target Offset are similar in this regard. The Target Offset measure is for A to B only, leaving B to A and all the rest alone. The phrasing of the exception (The Target Offset is at least 24 CSS pixels to every adjacent target) accounts for all the rest. It is very neat how the SC works with this exception, and the exception works with the definition. But I agree that the visualization of horizonal and vertical lines is simpler (since, if the target has straight edges, the chosen starting point is flexible, and lines obviously end at the nearest neighbor) as compared to circles (where discerning a telling placement might not be readily apparent).
Yes! Very nice, the left/right and top/bottom qualifiers are not needed, so that is a simplification. Also to @dbjorge concern for "edge" (and your suggestion to use "point" instead), so that leaves this note as:
|
Sorry to ask, but for targets which are not (horizontally nor vertically) aligned -- is "size" too vague? Wilco provided a some examples. How does one measure the target offset for a star near crescent moon? Should we have a note that size == bounding box? |
|
I very strongly agree that "size" is too vague. I don't think it's apparent whether "size of a target (A) plus the spacing to a second target (B)" is defining an area or a length. I think this is much more ambiguous than the previous version, which I think this huge thread has demonstrated was already too ambiguous. edit: split this out into #2803, since it also affects the primary part of the SC, not just the target offset definition |
|
I think @mbgower solved this on the call Tuesday! We use center/centroid. That (1) makes the exception simpler and (2) eliminates need to define "target offset" as a defined term.
It would be nicer to just use "center". Or maybe add Note to end of SC? (E.g., "For targets that do not overlap and have simpler shapes, center and centroid are equivalent.") |
|
Yes. We can use centroid to cover the bases accurately and add a note along the lines Bruce’s comment suggests.
NOTE: For regular shapes (squares, ovals, circles, triangles, etc.) the centroid will be the center.
(Or ….the centroid and the center are the same)
- check with plain language folk to see which is better construction.
… On Nov 25, 2022, at 6:16 AM, Bruce Bailey ***@***.***> wrote:
I think @mbgower <https://github.com/mbgower> solved this on the call Tuesday <https://www.w3.org/2022/11/22-ag-minutes#t06>! We use center/centroid <https://en.wikipedia.org/wiki/Centroid>. That (1) makes the exception simpler and (2) eliminates need to define "target offset" as a defined term.
Spacing: There is at least 12 CSS pixels from the target's centroid to every adjacent target;
It would be nicer to just use "center". Or maybe add Note to end of SC? (E.g., "For targets that do not overlap and have simpler shapes, center and centroid are equivalent.")
—
Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXT774M2PBCLIRBV5BLWKDC4PANCNFSM6AAAAAAQY7PAMA>.
You are receiving this because you were mentioned.
|
|
coming in very late and sideways on this, but ... I remember aeons ago suggesting centroids and circles, along the lines of "it's possible to draw a circle from the centroid with 12px radius, and have no other targets in that circle", but that idea was then abandoned because i seem to remember it caused issues with certain cases... might have been back on mailing list discussions |
|
ah, was thinking of this i think, but i'm sure i floated something like this even earlier #2159 (comment) |
|
Welp, I am sorry to say, there are some common patterns where using center/centroid this way fails perfectly reasonable/useable/accessible UI. Consider a bull's eye target with a 24px diameter circle at center, a decent gap (but less than 24px), and a decent sized ring (but less than 24px thick). The circle and the decent-sized-ring have the same center/centroid. |
|
Good point
That takes us back to the originally suggested wording. "There is a point in the target that that is simultaneously XXX Pixels distant from the nearest edge of all other targets"
This can be proven by drawing a circle with a XXXX Pixel radius - and seeing if there is any location where the circle does not overlap any other target - and the center of the circle is anywhere inside the target being evaluated. This would also make it easy to reposition any target to make it pass if it failed.
… On Nov 27, 2022, at 1:26 PM, Bruce Bailey ***@***.***> wrote:
Welp, I am sorry to say, there are some common patterns where using center/centroid this way fails perfectly reasonable/useable/accessible UI.
Consider a bull's eye target with a 24px diameter circle at center, a decent gap (but less than 24px), and a decent sized ring (but less than 24px thick). The circle and the decent-sized-ring have the same center/centroid.
—
Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXTOZ3X5UPINIADOA5DWKPGY3ANCNFSM6AAAAAAQY7PAMA>.
You are receiving this because you were mentioned.
|
That promotes 1x1 targets. A developer might put decoration (making the some of the dead space visually seem as part of the target) but that hides the reality of the UI. It might be okay for a "fat thumb" UI but it is poor for mouse users. Still, I think this might work as a spacing exception, just not the baseline requirement. From this week's survey, @WilcoFiers suggested exception of target offset of 24 px where:
|
|
Agreed
This should only be use in connection with a minimum button size.
The wilco text also allows for a 1 pixel button - but doesnt reward smaller buttons with closer spacing.
- not sure how to apply it with 'buttons' that are not a regular shape. If you have something with a long panhandle you can end up with the person having to hit the handle to stay away from next object. I know we discussed this but don’t remember the solution? I think the minimum minimum height and width was talked about but for a circle the min would be 1 pixel and if we went minimum maximum it doesnt solve the panhandle problem.
Maybe we just focus on regular shapes?
Or set a min high and width at the center of the object?
gregg
… On Dec 15, 2022, at 6:55 AM, Bruce Bailey ***@***.***> wrote:
There is a point in the target that that is simultaneously XXX Pixels distant from the nearest edge of all other targets
That promotes 1x1 targets. A developer might put decoration (making the some of the dead space visually seem as part of the target) but that hides the reality of the UI. I might be okay for a "fat thumb" UI but it is poor for mouse users. Still, I think this might work as a spacing exception, just not the baseline requirement. From this week's survey, @WilcoFiers <https://github.com/WilcoFiers> suggested exception of target offset of 24 px where:
Target offset is the length of the longest line that starts at an edge of A, intersects a second edge of A, and ends at an edge of B.
—
Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXTCFYDD6FQTJP4LZADWNMWOPANCNFSM6AAAAAAQY7PAMA>.
You are receiving this because you were mentioned.
|
|
What about combining "There is a point in the target that that is simultaneously XXX Pixels distant from the nearest edge of all other targets" with a hard minimum on target size about that point to avoid the 1x1 target possibility? Something like:
This can be visualized by thinking about overlaying one 12px and one 24px circle both centered on a tester's mouse pointer - if it is possible to position the concentric circles such that the inner circle lies entirely within the target and the outer circle does not touch any other target, it's a pass. Fundamentally, if the intent of the requirement is to demand that there be some spot in the target which most users could attempt to press/click and have:
...then I think the requirement should written in terms of demanding that such a spot exists in the target. Unless I've misunderstood the intent of the requirement, I think it's nonsensical for the requirement to be written in terms of pairwise measurements with every adjacent target, regardless of the specific language of the pairwise measurement. A human trying to press a button is pressing one spot at a time on the button. They don't have a quantum mouse pointer that is trying to press some superposition of one spot per adjacent target. I don't think "avoiding encouraging 1x1 targets" is a good enough reason to accept a nonsensical measurement. We should come up with an option which is based on the actual intent of the requirement and which avoids encouraging 1x1 targets. |
|
The spacing exception does not have to imply pair-wise measurements.. It is just an exception:
or
It is only a target's nearest neighbors that need to be considered. The base requirement sets a minimum size. The exception does not have to include size if we use Wilco's definition.
Just saying something like 24 px spacing between targets encourages a sparse 1x1 targets. 24 px Target Offset counts target size plus spacing. Follows is a simple illustration, two sets of ten targets using the same canvas. The first is X target spacing, so mostly white space. The second is X Target Offset -- with much larger targets (for mouse cursor), but same canvas size., same X size to hit with a "fat finger".
|
|
Update from the friday meeting:
So we're looking at this as the update (SC text, definition, note):
|
Is this suggesting that there is any data that supports the current form of the spacing exception (with or without the #2798 updates)? If that exists, it would be good to reference it in the understanding doc. Right now, I think the only research it references better supports using an approach measured from the center of the target, not a target offset based approach. |
|
Data in this sense includes practical application on the web.
We don't have a basis for picking a smaller number to use as an absolute minimum size, either from user-research, or practical platform considerations. Slight tangent, but presumably the testing in the research did not incorporate the heuristics that mobile OSs use to guess the intended target? As people are consistently wrong about where the centre of their tap is, touch-interfaces will make a guess that improves perceived accuracy compared to where people actually touch. |
|
Correct
And they also look for center of touch — so touching more than one key onscreen does not press more than one key - as it does in the real world
Note 1 - as per Alastair - we don’t usually touch where we think we do
Note 2 - as you press and release - the 'center of you press moves - and that is also taken into account when figuring out where you press — another thing about soft keys that is not true for hardware keys
gregg
———————————
Professor, University of Maryland, College Park
Founder and Director Emeritus , Trace R&D Center, UMD
Co-Founder Raising the Floor. http://raisingthefloor.org
The Global Public Inclusive Infrastructure (GPII) http://GPII.net
The Morphic project https://morphic.org
… On Dec 19, 2022, at 1:11 AM, Alastair Campbell ***@***.***> wrote:
Data in this sense includes practical application on the web.
We started at 44px (aligning with touch-interface platform standards).
We dropped to 24px as there are plenty of examples of usable interfaces with buttons (e.g. toolbars) at that size. (They may not be usable for everyone with mobility issues, but increasing the size of those buttons triggered negative impacts in other areas, e.g. low vision.)
We allow for spacing as well as size as that prevents mistakes, even if people aren't successful in triggering the intended target. It also helped us get over objections.
We don't have a basis for picking a smaller number to use as an absolute minimum size, either from user-research, or practical platform considerations.
Slight tangent, but presumably the testing in the research did not incorporate the heuristics that mobile OSs use to guess the intended target? As people are consistently wrong about where the centre of their tap is, touch-interfaces will make a guess that improves perceived accuracy compared to where people actually touch.
—
Reply to this email directly, view it on GitHub <#2695 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGDXXTA452NSA3QINBBVTWOARE7ANCNFSM6AAAAAAQY7PAMA>.
You are receiving this because you were mentioned.
|
To be clear, what I'm asking for is whether there is any data/user research/etc that supports the specific choice of spacing exception algorithm. So far, it does not appear that there is any basis in user research to support whether the current target offset per-other-target based approach, a "offset from center" approach, or a "offset from single fixed point" approach would result in lower mis-press rates for users. It is confusing and frustrating that "we don't have a basis for picking this based on user-research or practical platform considerations" is a blocker for a minimum size but does not appear to be a blocker for the choice of spacing exception algorithm. One of my colleagues pointed me to this Summary of Research on Touch/Pointer Target Size writeup from the Mobile Accessibility Task Force several years ago, which includes pointers a few studies that seem applicable, but in general the ones that include study of spacing recommend having certain spacing amounts in addition to suggested target sizes, not as an exception to them.
Yes, that's probably the case - that specific study cited by the 2.5.8 understanding page documents that it was performed in 2005 on an HP iPAQ h4155, so it wouldn't include any modern mobile OS heuristics. I think that's a good example of why this single study is not sufficient to serve as the only referenced source for the SC. |
Or whether it makes any difference at all when the target is under 24px.
Exactly, and at <24px I'm very sceptical there would be any significant difference between approaches. So the best effect we can accomplish is to provide consistent results. Using a measure from the centre incentives smaller targets. The current approach has at least gotten consensus in the group and been through a couple of wide r 846F eviews. This is a refinement of that approach. |
I've been working on an automated implementation of the Target Size (minimum) criterion in axe-core. (It's available via
npm install axe-core@latestif anyone wants to try it.) It's working reasonably well, but I keep running into scenarios where something that looks like it should fail doesn't. Take the following list of links - things like this happen a lot in table of contents:The links are 17 pixels tall, with 4 pixels whitespace between them. That would suggest they all fail. That's overlooking the fact that offset can be a diagonal. In this scenario, link C is actually the only link that fails the success criterion. The other two links have their offset measured on a diagonal, which results in them passing.
I've seen this happen in a number of places. ToC, navigations, I've seen it in inline links lists too (Wikipedia has lots of these at the bottom of its pages). Thinking about it in terms of "is there a spot on the link I could try to hit without accidentally hitting the wrong thing", this approach does make sense. Link A sticks out on the left, link B sticks out on the right. That works, and maybe this is just some artefact of WCAG 2.2 that people are going to need to get used to.
On the other hand, if someone wants to click link B, should they just assume that link A and C inline links, so that their touch area doesn't extend to the right? I'm not convinced that this is right. The other thing I'm concerned about is if testers start doing this very precisely, the people getting test reports are not going to understand why in a link of lists that are equally spaced, some links pass while others fail.
I'm not sure what to suggest on this one, but I wanted to share my experience with implementing this SC into a tool. I'm finding issues with this all over the place. It's a real challenge, and it's giving me serious doubts about if we got the math right on this.
The text was updated successfully, but these errors were encountered: