Rename Focus Not Obscured SCs to Focused Component Not Obscured

[patrickhlauke]

This is a proposed normative (but backwards-compatible) change for a potential WCAG 2.3

---

The name of these two SCs is confusing, particularly because other SCs (Focus Visible, Focus Appearance) refer to the focus indicator with the "Focus" shortform, whereas these SCs refer to the focused component.

x-ref #3950 #5194

[netlify]

❌ Deploy Preview for wcag2 failed.

Name	Link
🔨 Latest commit	2b921af
🔍 Latest deploy log	https://app.netlify.com/projects/wcag2/deploys/6a67e8ad9a27f20008fa0b33

[yatil]

YES, PLEASE!

[bruce-usab]

This would be a helpful class 2 editorial change. The current short name is misleading because the SC is about the component, and not the focus (border) applied to the component.

[patrickhlauke]

@bruce-usab if you think this could be turned into an erratum for 2.2 rather than something set aside for a potential 2.3 ... happy to move it. was just anticipating lots of (usual) pushback.... (i see there's already a thumbs-down, no surprises)

[ljkoakley]

I do not agree with changing the name to refer to a component. Web pages contain components but focus can be on a specific area within the component. As an example, the component "grid" with many lines of content with the edit icon at the end of the line. The grid can be partially behind a pop-up or a drawer, if the focus is on the edit icon which is behind the pop-up or drawer, the component does not have focus, the edit icon has the focus.

[fstrr]

@ljkoakley The only thing that is changing is the name. The SC has always been about the focused component and that content isn't changing.

[bruce-usab]

I remember once hearing that the names of SC are not themselves normative. I looked for, but couldn’t find, anything about that — or even that “name” is the best way to refer to these handles/labels. Can anyone hit me with a clue bat?

[yatil]

The shortnames (that's what I have been calling them) are in the normative part of the spec, but their goal or task is to summarize the requirement or give it a name. They have usually no bearing on how to interpret the success criterion itself (which are the paragraphs following the shortnames).

So changing them changes normative text, but should never have bearing on the normative interpretation.

Case in point: despite this SC's shortname referring to the focus not being obscured, the SC text makes it clear that the focused component cannot be obscured.

NB: If it was on me, I would even do a more drastic change to the shortname: Focused Component not entirely hidden

That would put it in line with the SC text, where obscured isn't used.

[patrickhlauke]

to @yatil 's point ... I think this may require further discussion when (if) we get to implementing this in (a potential) 2.3. I believe there is an intended difference here between "obscured" (meaning covered, overlapped) and the more general "hidden" (which could also include things like messing with the visibility or opacity of a component, positioning it off-screen, or similar). I believe the original intention was always to just cover the former (overlapped/covered) and not the latter. this is further reinforced by the current wording in the understanding document.

if this is indeed the case, i'd actually flip this suggestion around and say the normative SC wording should be changed to say "obscured".

[yatil]

I think (and I maybe remembering that wrong) that the reason for the SC wording came from an inability to properly define what "obscured" meant. Would it only apply to content (web example) that has a higher z-index, for example. I (might falsely) remember that using hidden in general was much easier to define and also more universally useable across technology.

(That said there is a certain overlap with "Focus visible" currently, which is not necessarily bad.)