Can we consider a technique to meet Focus appearance that exposes tooltips?

[mbgower]

I am wondering if we should consider providing sufficient or supplementary techniques which can be used to enhance focus indication where the main focus indicator fails to meet the minimum criteria. An example would be the use of a tooltip that is exposed on focus.

A use of this technique exists in Google docs.
Before focus comes into play, the toolbar hosts many icons without lablels, as well a few controls with visible text, such as "100%", "Normal text", and "Arial".

Figure 1: Screen snippet of Google docs toolbar showing a series of icons above and beneath the text-based menubar

As a user tabs into the icons, a faint gray outline appears on focus which does not meet 3:1 against the background. However, for almost all the icons, a high-contrast tooltip appears, revealing the icon's label. These tooltip icons reinforce the item with focus.

Figure 2: Low-fi photograph of portion of the same toolbar. The focus in on the Star icon to the right of the document title. It is shown by a faint grey rectangle (with curved corners) that fails 3:1. It also shows a tooltip reading "Star" that appears below the star icon.

My feeling is that this supplemental indicator allows the focus to be met, where the tooltips appear.

However, where they do not appear, the indicator would fail. This failure exists on only a few icons in the whole toolbar:

• the profile buttons that show when someone else is actively viewing the document
• the other Google application icons that are vertically shown on the far right side of the screen (although these icons have tooltips that display on hover, they do not appear on keyboard focus

Figure 3: Another photograph of a portion of the toolbar, showing a thick but faint gray focus ring around a circular image of a single user (which is persistently stroked with pink; that is not part of the focus indicator)

Figure 4: The same portion of the toolbar,this one showing the focus now on the circular icon immediately to the right of the user icon. The thick grey circular focus indicator fails contrast, but the tooltip displays "Show chat", making it clear what has focus.

Figure 5: The Google calendar icon has focus, represented by a very light gray filled circle around the icon. No tooltip appears, so the focus indicator is insufficient.

[patrickhlauke]

the SC doesn't differentiate (I think) between "primary" and "secondary"/"additional" focus indicators, so everything that appears on focus/indicates focus (in this case, including that tooltip) to me count as part of just the "focus indicator". though referencing the perimeter/bounding box of the control, in this case, will be a bit odd/unrelated to the size of the tooltip...

[mraccess77]

I would think a tooltip that appears on focus could be used in the calculations for this criteria and as a way to meet it. The fact that indicators could overlap other content on the page and thus may need to meet SC 1.4.13 does complicate things though.

[mbgower]

The fact that indicators could overlap other content on the page and thus may need to meet SC 1.4.13 does complicate things though.

Yes, but because they persistent until dismissed, and Esc dismisses the tooltip, this implementation passes 1.4.13.

[LaurenceRLewis]

Could this be covered by: Minimum area: The area is at least as large as the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the area is thinner than 2 CSS pixels.

...or the area is at least 4 CSS pixels in diameter, and is visually associated with the controlling element.

If the tooltip meets Success Criterion 1.4.13: Content on Hover or Focus, would the tooltip be sufficient to meet the SC based on the minimum area?

[detlevhfischer]

My hunch is that the real estate (surface area) of a tooltip will nearly always be much bigger that the required area derived from the outline of the target (certainly for icons, maybe not for large tiles). I would consider this a PASS whenever the position of the toolbox (or some trait like the triangle arrow in the Google example) unambiguously link tooltip and focused element.

[mraccess77]

SC 2.4.11 doesn't say what the focus indicator needs to look like or even where it is - so as long as the indicator meets the requirements it would seem to pass. I could imagine it might be more tricky to test some aspects and personally I'm not sure it's a great indicator that we would want to promote - but it could be used to meet the criterion as written. Personally I think it could be confusing and I agree proximity is important as well - but that's not addressed by the current criterion.

[JAWS-test]

I had suggested including a requirement in the new focus SCs that the focus must clearly assignable to the element, but unfortunately this was rejected

[bruce-usab]

@JAWS-test — can you point me to the prose you suggested? IMHO clearly assignable to the element is too vague.

I would also note that we do have AAA 2.4.12 which we might add to as well.

[patrickhlauke]

IMHO clearly assignable to the element is too vague

there's basically a risk of either being far too vague and not really unambiguously testable, or on the other hand establishing some very complex and specific (but rather arbitrary) parameters on something that is inherently to do with design, usability, "wooly" concepts (i.e. having to justify why it can only be x css pixels away from the control to "count" as being clearly visually related to it etc)

[JAWS-test]

@bruce-usab

I had built some examples to show that a focus indicator alone is not sufficient to identify which element has the focus, e.g.

• if the focus indicator is on another element
• several elements share a focus indicator
• the focus indicator consists of the focus indicator of a group being removed
  etc.

https://codepen.io/jaws-test/pen/qBZpWdw
https://codepen.io/jaws-test/pen/KKzyrXO
https://codepen.io/jaws-test/pen/xxxJNQY

See #1383 (comment)

[JAWS-test]

Further problem with the focus indicator can be that it is only visible during operation (due to the dynamic change), but not, for example, when looking at the screen after a distraction or when a new screen section is scrolled into the visible area due to tab operation.

See e.g. https://codepen.io/jaws-test/pen/qBPQXRB

[mraccess77]

Focus indicator would need to be persistent in my opinion unless the user has done something to make it not-persist. If the user scrolls it out of view with keyboard it should still exist and should come back.

[alastc]

Put in a note near the top that say tooltips / toggletips often have accessibility issues.

Suggested test procedure:

For controls which have a focus indicator that appears like a tooltip:

• The tooltip appears next to the control.
• The tooltip has sufficient size and contrast to pass focus appearance.

NB: Also needs to pass "Content on hover or focus", and other SCs.

[mgifford]

Keyboard and touch devices definitely need to be considered. So often the tooltip ends up containing important contextual information which is hidden.

[gundulaniemann]

I think using the tooltip as focus indication is not suitable for several reasons.

• a tooltip in its standard presentation is a bare rectangle. It does not uniquely indicate which item it belongs to.
• a tooltip can be triggered on hover. The focus might be on a different element. Focus and hover a very different states and can apply at the same time to different elements.
• not all interactive elements have a tootltip. A save button named 'Save', for example, does not necessarily have a tooltip. adding one would add visual noise for sighted users and audio noise for scren reader users.
• a tooltip as a little delay before showing for a reason: to avoid visual noise and flickering effects. The focus must be visible immediately.

[stes-acc]

Allowing tooltip excusively to identify focus position leads to the fact that it needs to be applied to things that normally need no tooltip, e.g. to a button labelled "Save" with tooltip "Save" which is pointless. And saying then tooltip should be different to avoid that adds annother level of unneccessary complication.

But even more important is that this definition BINDS "focused" state to "has Tooltip" property and is therefore a strict dependency/coupling between two object propertys that were not interdependant before, which is generally an architecture violation.

Also this opens a can of worms for validators. Do they need to check now in their focus appearance checks if title attribute is non-empty for a elements that do not render a visible focus by whatsoever reasons? And so on ...

[detlevhfischer]

We have no normative text setting down rules as to where the indicator must be relative to the element in focus, regardless whether custom tooltip or other indicator. In the absence of that, any non-normative text saying the focus indicator must be closer the the element focused than to others etc. is bound to run into trouble in view of the possible variety of implementations. In @mbgower's figure 2 above, the custom tooltip sits on top of another interactive element (so it is closer to that than to the one it points to) and it is the little triangle/arrow of the tooltip that does the heavy lifting. We really only have 1.4.11 to hold it to sufficient contrast.

I think everyone agrees that custom tooltips are not a great way to indicate focus, but the arguments by @gundulaniemann and @stes-acc do not, in my view, conclusively rule out that such a tooltip could be meeting 2.4.7 - whatever other troubles or SC failures or indeed usability issues that might cause. The user need of 2.4.7 is to see where the current keyboard focus is, and where the tooltip is sufficiently contrasty, does not auto-disappear, and is associated with the element in focus, I cannot see how that would clearly fail 2.4.7.

[gundulaniemann]

Exactly, as using the tooltip to indicate the focused element causes a lot of trouble, it is not recommended.
As a consequence, this method should not be given as a sufficient technique.

[detlevhfischer]

@gundulaniemann I am not sure what your "exactly" is referring to. To be clear, I guess no one here would recommend custom tooltips as a focus technique or plans to author a Sufficient Technique supporting it, but that does not mean that it necessarily fails 2.4.7 - that was my point, at least...

[patrickhlauke]

If a technique were to be written that shows cases where a tooltip can, in fact, be counted as a sufficient way to indicate focus, it would obviously need to be crafted in such a way as not to suffer from the various problems mentioned, if possible... i.e. not have a delay, not only be styled as a rectangle with no clue what it refers to (e.g. by adding a little arrow/speech bubble notch, and/or overlapping the element it refers to, etc), and only be used on controls that warrant a tooltip (while others like a textual "Save" button would have a more traditional border/outline).

So I wouldn't discount a well-crafted tooltip as NOT counting as a focus indicator, but it would obviously be done really well and serve its purpose to inform users which element has focus in a "clear" way (for whatever definition of clear)