RE: Messages from previous editors on 2.4.7 focus visible

Hi David,

Thanks for that, knowing it wasn’t considered at least sets the context. I don’t think ‘not considered’ means ‘not covered’ though, so let’s tackle two aspects:


  1.  Is this scenario covered by the current SC text?
  2.  If we intend to cover it now, how would that work?

1) For the SC text:
Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

My personal opinion is that the focus indicator *is* visible, but the whole element is obscured. Additionally, the term ‘mode of operation’ adds a little flexibility and if the user can scroll to view the element, that would pass.

2) If we did try to cover it in the new SC, MichaelG, Detlev and I had a little email discussion and thought we could try adding this bullet to the new SC:
“- Unobscured: The item with focus is not hidden by author-created content.”

This is the latest copy of the SC text:
https://raw.githack.com/w3c/wcag/wcag22-focus-visible-enh-updates/understanding/22/focus-visible-enhanced.html


Thinking about this addition there some difficult questions, such as:


  *   In a context where we have defined ‘visible’, what happens if one edge (or half) of the element is not visible? For example, even without a sticky footer the browser will often not show the lower-edge of the element, therefore some of the outline can be cut-off.
If we include this aspect it could be a failure of the 1st bullet about indicator size.

  *   What happens if the user zooms-in or adjusts text, and the height of the sticky footer changes? The current methods for avoiding this issue are brittle and it would lead to a lot of edge-cases where the focused element is partially or fully out of view.

Neither of these issues were a problem for the current 2.4.7 because it didn’t define visible, so if a 1pixel corner of the indictor were visible, that would count.

However, we do need to resolve this for the sake of the new SC.

Personally, I think the best option would be to consider the focus indicator independently of other layers of content on the page, as that is what is under author control. As soon as you include other aspects such as user-agent behaviour or other layers of content, we get into a very messy and un-testable situation.

Also, I think the overall improvement from strengthening the visibility of focus-indicators is more beneficial than tackling this case that is much less common, at least on websites I visit or test.

If we agree on that, we should then look at a normative basis for both this focus-hiding aspect, and the zoom/reflow issues with sticky content, but that would be a 2.3/silver thing.

Cheers,

-Alastair


From: David MacDonald

Hi All

After our discussion last week about 2.4.7 I took the liberty of contacting the two previous chairs of WCAG 2.0 to get their recollections of 2.4.7 and whether it applies to layered content where focus is temporarily obscured behind a layer. Here is my question to them with their answers.

===David MacDonald's question===

There is a very animated WCAG discussion on the working group about SC 2.4.7<https://www.w3.org/WAI/WCAG21/Understanding/focus-visible.html> focus visible,

Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.

The group has no consensus about whether it was intended to cover the scenario where the user tabs to a component which is behind a sticky header/footer etc, and is temporarily obscured, but if the user scrolls (or presses the spacebar) the component becomes visible with its focus ring visible.
My sense was that if the component can be shown with a simple action like scrolling and the focus ring is correctly implemented, then the SC would be met... but it's quite a dynamic discussion.

I'm wondering about your thoughts about that which would help provide context.

=== Loretta Guarino Reid (PhD Computer Science), WCAG 2.0 chair and accessibility at Google ===

Nice to hear from you! I hope all is well with you and yours.

This is a very different question from the sorts of things I remember us discussing. The use of layers of UI elements and regions was not common then, and we were more focused on making sure you could find the focused element in the two-dimensional area of the window.

I'm not sure what I think the answer should be, either. For someone with low vision, having the focus highlight (and focused element) completely obscured poses real challenges. But how could such situations be avoided in the 2.5 dimensional world we find ourselves in? Would there need to be some user agent support for rearranging the top layer to uncover the focused item? How would the user know what to do? Yet, I can't see the web going back from these design patterns.

No wonder this has lead to extended discussion!

I'm afraid I am not being much help, but this is certainly an interesting problem to think about.

====== Gregg Vanderheiden (PhD Engineering, former WCAG 1 and WCAG 2 chair)  ====
Here is another one for the history books.  (That is — the place where they archive all the history and lost information on the guidelines.    They created one a while ago.  Do you know where it is?)

MY MEMORY
What we WANTED to say was that “the Keyboard focus indicator was highly visible”.   But that is not testable.    So we went with “visible” and used that as an anchor to provide advisory notes that the focus indicator should be highly visible — that is — visible from 10 times the normal viewing distance or more.

So as it is - - it is pretty hard to not meet it - unless you do something crazy and don’t make the keyboard focus indicator visible at all — in which case it is not a keyboard focus indicator….   That is - you don’t have one at all.

===David's Summary ====

- It was not the WCAG Working Group's intention when creating SC 2.4.7 to address layered content where a properly coded focus ring is temporarily obscured but can be shown by scrolling.
- SC 2.4.7 wording doesn't apply to layered content,
- There is no historical precedence to interpret it that way.
- There may be good reason to look at this as a new requirement for WCAG.NEXT, but layering is here to stay and this goes well beyond the question of sticky headers and footers, and is likely something that should be addressed at the browser level

The institutional memory homepage is here https://www.w3.org/WAI/GL/wiki/WCAG20/Institutional_Memory There is no content in there for 2.4.7.

I would add that in 20 years this is the first time it's been asked to us that I'm aware of. The request was from a power tester and not an end user. My guess for the reason we've not heard about it from end users, is the way the sighted keyboard users interact with content. I cover that in this blog entry.
https://www.davidmacd.com/blog/sighted-keyboard-only-user.html


Cheers,
David MacDonald