Invisible elements appearing on hover and focus - failure? If so, where?

[detlevhfischer]

I have a case where a checkbox in front of a row in a table only appears when the row is hovered over or once it receives keyboard focus. This is likely an accessibility problem for voice control users (and also, of course, a general usability problem for all users as its discoverability hinges on user actions on the page), but does not seem to fall under any particular success criterion.

One likely candidate is 1.4.11 Non-text Contrast - when focused, element contrast is sufficient (4,8:1 when suffuciently magnified to avoid anti-aliasing effects), when not, its contrast is 1:1 (=non existent). Is this sophisty of the "how can I punish that" kind?

[patrickhlauke]

I'm afraid that to me that's sophistry/clutching at straws. This is the scenario that the proposed "visible controls" or whatever it was called SC wanted to address, but that in the end was not added to 2.2 because it was proving difficult/impossible to normatively define where to draw the line

[detlevhfischer]

@patrickhlauke I thought you would say that and have the same gut feeling - is that the general sentiment here? Need to check whether this is now covered in WCAG 3.

[detlevhfischer]

FYI: I have checked and this aspect does not yet seem covered in WCAG3 - in one requirement, the focus is on (visually) disinguishing between interactive and non-interactive content (which I assume will be harder to nail down than the difference between visible / invisible). Have left a comment in my trial testing od WCAG 3 requirements.