Clarification on SC 2.5.8 Target Size Minimum alternatives and wording constrained by line-height of non-text non-target text

[mraccess77]

I've found that pagination is an example where undersized targets can exist and overlap can occur

1. If next and previous links in pagination have sufficient target size but numbered page links are undersized and overlap does this meet the alternative equivalent for this criterion? In this case, the alternative may require multiple user actions compared to the non-alternative.
2. Does the constrained by line-height requirement apply when the overlap issue isn't height but width and how can you tell what is the constraining factor?
   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.

[detlevhfischer]

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).

[JAWS-test]

@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.

[detlevhfischer]

@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.

[JAWS-test]

and the FAIL occurs as much on that other target for deleting data as on those in the row

It doesn't have to be, because the control for deleting can be large enough

[detlevhfischer]

@JAWS-test True!

[mraccess77]

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.

[fstrr]

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.

[mraccess77]

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?