RE: Messages from previous editors on 2.4.7 focus visible

I'm not quite ready to give up on this one yet. :)

A revealing moment on last week's call was the poll where everyone thought 
the sticky footer obscuring the item with focus SHOULD be a failure (may 
have been one person vote zero?).

That kind of consensus doesn't happen all that often, not does a situation 
where we have an obviously relevant new 2.2 SC, already in the draft, on 
which we can iterate (with the understanding that if we don't get 
agreement on the addition, it just stays in its current 3-bullet form).

I have a suggestion for rewording which I think addresses Alastair's 
concerns:
“- Unobscured: The focus indicator is not entirely hidden by 
author-created content.”
 
His stated misgivings were:
>
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.


The new wording fully addresses bullet one. As long as some part of the 
focus indicator is not obscured by author-created content, it passes. It's 
not ideal, but it is very clear, and it will have a demonstrable 
improvement for anyone navigating by keyboard. I also wanted to point out 
that in his second sentence of this bullet, a portion of the element being 
offscreen would not have failed the former wording either; it's not 
obscured by author content. But that is now much clearer, in any case.

The new wording satisfactorily responds to the second bullet, IMO. Regular 
zooming by a user would never cause a fail this criteria in a UI, unless 
the author shoves something completely over top of the entire element with 
focus, including all its indicator. Same with, text resizing.  It's an 
author decision to use a sticky footer or other floating elements, and 
they have some responsibility to consider the ramifications of its use. 
Let's remember that sticky footers are a nightmare for keyboard users. 
Part of the viewport is constantly obscured by a footer, which a keyboard 
user can never reach without resorting to a mouse.



Michael Gower
Senior Consultant in Accessibility
IBM Design


1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
cellular: (250) 661-0098 *  fax: (250) 220-8034



From:   Alastair Campbell <acampbell@nomensa.com>
To:     WCAG <w3c-wai-gl@w3.org>
Date:   2020/05/20 04:50 AM
Subject:        [EXTERNAL] 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:
 
Is this scenario covered by the current SC text?
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 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