Where to fail focusable unclear functional eIement without visible description #5145

I'd agree with your own diagnosis here, this looks like a genuine and fairly well known gap in WCAG 2.x rather than something with a clean Fail path. Walking through the candidates systematically:

What passes cleanly

Success Criterion 2.1.1 Keyboard is met. The control is reachable and operable by keyboard, full stop.

Success Criterion 2.4.7 Focus Visible is technically met. There is a visible focus indicator present, even if it's easy to miss.

Success Criterion 4.1.2 Name, Role, Value is met. The programmatic name ("show controls of video player") is meaningful and accurate.

Where it doesn't quite fit, even though it feels like it should

Success Criterion 2.4.6 Headings and Labels deals with the quality of a label that exists ("describes topic or purpose"), not the complete absence of any visual affordance. Since there's no visible label or icon at all here, this is a coverage gap rather than a literal failure of the criterion's text.

Success Criterion 3.3.2 Labels or Instructions applies to input fields that require user-entered data, not to a control button like this, so it doesn't apply either.

Where you probably can file something concrete

Success Criterion 1.4.11 Non-text Contrast — check the contrast of the small blue square against its background. If it doesn't hit 3:1, that's an independent, clean Fail regardless of the size question.

Success Criterion 2.4.13 Focus Appearance (new in WCAG 2.2, AAA) is the most on-point match for the size problem specifically. It sets a minimum area for the focus indicator (either a 2 CSS px outline around the whole control, or an area equivalent to a 2px outline along the control's shortest side) plus a 3:1 contrast requirement. A tiny square in the corner of a video player is very likely to fail this outright. Since it's AAA, you can't cite it as a formal Fail against an AA conformance claim, but it's exactly the kind of finding that belongs in an "exceeds AA, recommend considering AAA" note or as an advisory finding.

My overall take

I don't think there's a WCAG 2.x success criterion that cleanly and defensibly fails this as written. It's precisely the kind of case people point to when arguing for a "visible affordance" concept, something that shows up in WCAG 3 (Silver) proposals but has no explicit equivalent in 2.x.

Practically, I'd handle it as:

• Fail on Non-text Contrast (1.4.11) if the contrast ratio doesn't hold up, independent of size
• Advisory finding (outside the formal Pass/Fail scale) referencing the intent of Guideline 2.4 Operable and Focus Appearance (2.4.13), noting that a focus indicator this small defeats the purpose Focus Visible was written for, even though it technically passes
• No clean AA Fail for the "what does this button even do" problem itself, that part really is the gap you suspected

I guess the answer is, "sorry, nowhere, this is a gap in WCAG 2.X, wait for WCAG 3", but I ask anywhere in case others have a good idea where such content might FAIL.

This is the situation, checking keyboard operability:

1. On the page, you have a video without visible controls
2. Hitting "Play" shows a dialog telling you your data will be bled to YouTube. You OK it.
3. Again you hit "Play"
4. Video starts playing with nasty bg music etc - no controls to stop it (unless you hover over it)
5. You tab through the video. If you look closely, there's a tiny blue square visibly focused in the top left corner - no visible indication (neither description nor icon) indicating what it does
6. Activating the tiny blue square displays the video's controls

The tiny blue square has a meaningful programmatic name: "show controls of video player" - but this function is not evident to sighted keyboard users (quite apart from the fact that the control is tiny and fails 1.4.11). It is operable, so I guess it does not fail 2.1.1.

Any ideas?