Open patrickhlauke opened 4 months ago
patrickhlauke
commented
4 months ago I mean, the most naive/simple solution for the overlap would be a straight-up acknowledgement that when something fails 2.4.11, it automatically also fails 2.4.7 (when the focus is "obscured", it clearly also "isn't visible" by virtue of being "obscured").
patrickhlauke
commented
4 months ago And yes, also acknowledging the fact that - at least from many conversations following 2.2's release - 2.4.11 / 2.4.12 refer to the focused element or control, while 2.4.7 talks about the focus indicator ... so sure, there certainly can be cases where the element is obscured, but there's still remnant of its indicator visible, which would be cases where something fails 2.4.11 but passes 2.4.7...
In short, this awkward overlap is causing unnecessary handwringing and confusion when now trying to decide what to fail certain situations under (situations that, in the past, I'd have very happily already filed as a failure of 2.4.7 when both the element and its indicator weren't visible)
yatil
commented
4 months ago IMHO “2.4.11 Focus Not Obscured” should have been “2.4.11 Focused Element Not Entirely Hidden” as that reflects better what the SC says (in my interpretation).
This is all complicated by 2.4.7 Focus Visible not actually defining that every UI element has a visible “keyboard focus indicator”, only that there is a mode that ensures that there is one. There are actually several things you need to know to interpret that as “everything that has the focus has a keyboard focus indicator”.
2.4.11 isn't concerned with the keyboard focus indicator, only with the focused element itself, while 2.4.7 is only concerned with the indicator but not with the UI element.
Obscured is also a weirdly specific language for the title, where the SC says, “not entirely hidden”.
There are basically four scenarios:
I agree, this would be cleaner if there was one SC that said, “Focused elements and their keyboard focus indicators are always at least partially visible” because I think that’s the goal of these two SCs in tandem. I also don’t think it’s terrible malpractice to test for it this way, considering that focused element hidden/keyboard focus indicator visible is something I can’t remember to ever coming across, even if it’s certainly possible to happen.
melaniephilipp
commented
4 months ago The “…has a mode of operation…” portion of 2.4.7 has always stopped me from saying you can call a 2.4.7 failure in instances where things are temporarily covered by content such as a modal dialog (agree, a 2.4.3 failure if focus isn’t sent to or trapped in the modal), or a menu that is opened and there is content focusable behind the submenu, or a cookie consent banner covers focusable content. In instance like those, there is a “mode of operation” where the content is visible when focused: close the modal, close the submenu, dismiss the cookie banner. If 2.4.7 already covered those scenarios, why did we need 2.4.11?
patrickhlauke
commented
4 months ago yatil
commented
4 months ago The “…has a mode of operation…” portion of 2.4.7 has always stopped me from saying you can call a 2.4.7 failure in instances where things are temporarily covered by content such as a modal dialog
I think this is a failure of WCAG not defining what “mode of operation is”. The Understanding has a definition, which I chose to interpret as “if you can use the keyboard, and there is a way by the User Agent to display focus styles, then everything needs to have a visible focus”:
“Mode of operation” accounts for user agents which may not always show a focus indicator, or only show the focus indicator when the keyboard is used.
In instance like those, there is a “mode of operation” where the content is visible when focused: close the modal, close the submenu, dismiss the cookie banner. If 2.4.7 already covered those scenarios, why did we need 2.4.11?
Because 2.4.11 extends the requirements in a way that also includes that the UI element itself must be visible.
(But yeah, I agree that this could have been integrated better.)
mbgower
commented
4 months ago As pointed out by @yatil and @melaniephilipp, the division is between whether the item has a focus indicator and whether the item with the focus indicator is visible in the viewport.
The wording of 2.4.7, "Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible," has been interpreted by some to mean that if there is a means of bringing an item with focus into the viewport, even where it is not currently visible, then there is a 'mode of operation' in which the focus is visible. For example, if I can press the Down Arrow to scroll down the page and so expose an item with focus that has been hidden by an overlay prompting me about my cookie preferences (a common outcome of GDPR implementations), it does not fail Focus Visible.
2.4.11 fills this obvious situation, where many users were being disoriented and confused by the apparent absence of any focus indicator as they were tabbing through a page when the focus went behind the GDPR overlay. (While implementations to address GDPR are not the only situation where this occurs, it is a common one.)
Assuming this explanation makes sense to @patrickhlauke, if someone in the thread wishes to do a short PR to update the Understanding docs, it would be welcome. Otherwise, I'll undertake to do so.
patrickhlauke
commented
4 months ago @mbgower i'm aware of what the original idea behind 2.4.11 was, but your reply only covers part of my question about overlaps though. what happens when both the item that has focus AND its focus indicator are hidden/obscured? i'd assume it fails both 2.4.7 and 2.4.11. and if so, that should be explained/added. what happens when an element is not visible not because it's not obscured, but off-screen (like off-left) for whatever reason? it's not technically obscured by author-generated content. what about focus falling behind a modal dialog because the author hasn't managed focus correctly? fails focus order, focus visible, AND focus not obscured? there's a lot of interplays and moving parts and ... overlaps. and cases where some auditors will just fail things under one SC, or another, or all of them, or...
the problem isn't that the gap the SC tries to cover isn't clear. it's that the way it does so by also encroaching into areas that were already covered by other SCs...
yatil
commented
4 months ago what happens when an element is not visible not because it's not obscured, but off-screen (like off-left) for whatever reason?
I think this would hide the element.
it's not technically obscured by author-generated content.
The wording is not “by author-generated content” but “due to author-created content”. Content in WCAG is all HTML, CSS, JavaScript… If the cause of the hidden UI element is the author, the SC fails.
patrickhlauke
commented
4 months ago “due to author-created content”. Content in WCAG is all HTML, CSS, JavaScript
that's...a reach I'd say. of course everything is "author-created". the meaning of "not entirely hidden due to author-created content" is that it's not covered/obscured by author-created content (that sits over it). the author hasn't created the edges of the viewport that an element sits in. it's not covered/obscured by the content, but by the boundaries of the viewport in that case.
and again, this doesn't answer the overlap question at the heart of this either. even IF you interpreted it that way, would you fail just under 2.4.11, or both 2.4.11 and 2.4.7, or ...
yatil
commented
4 months ago I would fail both, see the four scenarios above.
In a recent discussion at my work, we've been trying to somehow define where the overlap between the classic 2.4.7 Focus Visible and the "new" 2.4.11 Focus Not Obscured is.
In the past (before the existence of 2.4.11), I have been known to file issues against 2.4.7 every time I was in a situation where "I move focus to a particular component, but I can't see any visible focus indicator on the screen". The reason why this was the case was usually not important to me ... whether it was because things were obscured by some content (for instance, focus is behind a modal dialog which doesn't manage focus correctly, which I would then also fail against 2.4.3 Focus Order), or because the focused element is completely outside of the current viewport (because the author moved a focusable control out of the bounds of the viewport and forgot to make it non-focusable ... which would again also have 2.4.3 implications), or cases where the page has something like a disclosure or dropdown, but they forgot to make the things non-focusable when the disclosure or dropdown is closed...
Now though, 2.4.11 appears on its face to be specifically aimed at some of these scenarios - such as the modal dialog case for instance - but not others. Where exactly is the cut-off point here then? Even when trying to rationalise it and saying it out loud, when focus is obscured, it's also not visible, so are these now scenarios where something fails both 2.4.7 and 2.4.11 (and in many cases also 2.4.3, when the root cause is badly managed focus order, like not keeping focus inside an open modal and having it instead fall back to the underlying page)?
At the very least, I think this overlap should be acknowledged somehow in the understanding for both 2.4.11 and 2.4.7. I don't think there's actually a very clearly defined cut-off point where something goes from a 2.4.7 issue to a 2.4.11 issue...unless we want to make the case that 2.4.7 should have never been applied to cases where focus is not visible because it was obscured by some other element (but then still make it apply when it was due to focus moving outside of the viewport, so not visible by virtue of its position, which seems a rather hairsplitting distinction).