Re: Messages from previous editors on 2.4.7 focus visible

Michael Gower wrote:

> 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.”


+1, that sounds quite accurate and useful.

JF

On Tue, May 26, 2020 at 9:09 AM Michael Gower <michael.gower@ca.ibm.com>
wrote:

> 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:
>
>
>
>    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*
> <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*
> <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*
> <https://www.davidmacd.com/blog/sighted-keyboard-only-user.html>
>
>
>
> Cheers,
> David MacDonald
>
>
>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
"I made this so long because I did not have time to make it shorter." -
Pascal "links go places, buttons do things"