Clarification on SC 2.5.8 Target Size Minimum alternatives and wording constrained by line-height of non-text non-target text #3829
Replies: 11 comments 1 reply
-
I think I would consider next and previous buttons which meet 2.5.8 as functionally equivalent (yes, you need more clicks, but you can get to the page you want). Otherwise, any functional alternative which needs more user actions than the 'default' (think of a drop-down as alternative to dragging in Kanban style scenarios) could not be accepted. Also, for a practical consideration, if the page number target gets smaller due to horizontal compression a click not hitting the proper target is likely to land on the adjacent target, from which the desired target can be then reached by one additional activation (next or previous). |
Beta Was this translation helpful? Give feedback.
-
@detlevhfischer I find it difficult to say that it is acceptable if I have a significant amount of extra work, to get from page 1 to page 100, for example, by having to click Next 99 times. Or what if the Next button is not there at all in the pagination, but hidden in a submenu - would that also be acceptable? Your argument that I can also click next to it and then be one page before or after my target page sounds plausible, but does not necessarily always apply, because there can also be controls above or below the pagination with which I delete data records, for example, and which do not have a sufficient distance to the pagination. In this case, you should avoid clicking on the pagination incorrectly. Before a final decision is made here, these questions should be carefully considered. |
Beta Was this translation helpful? Give feedback.
-
@JAWS-test As so often, it will be difficult to draw a clear line here since depending on the implementation, the practical issue may be very minor or more significant. In the example you mention (controls to delete data immediately above the row of page numbers) this would be a clear FAIL since two targets with a different function overlap, and the FAIL occurs as much on that other target for deleting data as on those in the row. Whereas the row of page numbers itself (assuming there are no other close targets) is not dissimilar to one target encapsulating a continuous range of values (as in a clickable slider groove), so using pointer, the worst that is likely to happen is that you land on an adjacent page an have to use prev or next to get the desired one. |
Beta Was this translation helpful? Give feedback.
-
It doesn't have to be, because the control for deleting can be large enough |
Beta Was this translation helpful? Give feedback.
-
@JAWS-test True! |
Beta Was this translation helpful? Give feedback.
-
Anyone else have thoughts on testing/determining if line height is a factor and whether line height here specifically refers to the CSS property? I saw the line height question come up again in a recent blog on this criterion from TPGI - so it seems like there are still questions on when to apply it. |
Beta Was this translation helpful? Give feedback.
-
This issue is labelled as a discussion, so we’re moving this to Discussions. There doesn’t seem to be an update to make to the documentation, but if that changes, we can move it back to the issues list. |
Beta Was this translation helpful? Give feedback.
-
We absolutely need an update to the document regarding what is meant by line height and how to measure that - but I'm not sure how to move back to an issue? |
Beta Was this translation helpful? Give feedback.
-
I think this mention of a different control being above or below the pagination is orthogonal to the discussion. That would clearly be a failure (at least in any situation I've ever seen; if you have a concrete example to show, please do). In the situation @mraccess77 has outlined, we're talking about a series of links appearing in a row, and the issue at hand is that the width of the links is limited because the text forming the link is limited. I think the un-stated original question was "Do page number links in a pagination pattern meet the Inline exception?" I would say "no". The Inline exception was intended to tackle two different scenarios that were very difficult for the author to fully control:
Neither of these things really apply in a pagination pattern. The author can easily increase the spacing above and below the complex component to ensure the x height is sufficient. The author can also create space between each of the numbers; there is no linguistic need for them to be spaced closely together. And, in fact, we see implementations of spaced numbers in the wild, such as my rateyourmusic album list. Note that they also offer what are effectively jumps of ten to give some level of granular control in their pagination. (Also, note that they've shimmed "1" and "2" to get to 24px; that won't happen on two-digit numbers, so pretty easy to address.) The Carbon Design System has shimmed the numbers so that all targets in a pagination control are sufficient. So there is evidence it is straight forward for authors to provide pagination with sufficient space; it doesn't need an exception. I think the Equivalent exception Detlev raises in an interesting defence, as is his perspective that this is one target with more granular points in it. I think that perspective is also secondary to the question of whether the numbers meet the Inline exception. (And Jon, please advise on whether I'm correct in my interpretation that his is your main question). |
Beta Was this translation helpful? Give feedback.
-
@mbgower
|
Beta Was this translation helpful? Give feedback.
-
@mbgower what I'm trying to figure out is how would you tell the average tester how to know "where the size of the target is constrained by the line-height of non-target text. ". What is the actual test for this that a person should do on a webpage? Does it involve looking for certain CSS properties or certain HTML elements or any link that has text next to it? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I've found that pagination is an example where undersized targets can exist and overlap can occur
a. The language around line-height seems to focus on the fact that links in text can wrap and thus you can't control those aspects in sentences and runs of text. What if the target link is not the issue - but instead it's the width of the target in pagination links? The note in the understanding doc says line-height should be perpendicular to the text - but the exception seems to apply regardless of whether the issue is height or width.
b. For the line-height - for HTML - is this focused on the line-height CSS property? Is the distinction where the line-height is not set on the target itself but on an ancestor? Does it matter if line-height is not set explicitly on an ancestor? Do any other properties like height relevant or just line-height? As an example, what is the best check for someone to verify this exception can or cannot be used.
Beta Was this translation helpful? Give feedback.
All reactions