Need clarity on Success Criterion 1.4.13: Content on Hover or Focus: Dialog Tooltips

[AccessibilityEnthusiastic]

Hi WCAG Community,

I need your opinion on one of the scenarios.

The tooltip appears on Dialog/Modal for the button.
When I press the Esc key, the entire Dialog getting closed, instead of closing the tooltip content of the button. Can we consider it as a failure under this checkpoint Success Criterion 1.4.13

As per WCAG:
Two methods may be used to satisfy this condition and prevent such interference:

Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
Provide a mechanism to easily dismiss the additional content, such as by pressing Escape.
https://www.w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html#dfn-mechanism
So Esc key is working but it is closing the entire modal rather than only the tooltip of the control.
It is a failure here?

[JAWS-test]

Using ESC to close the dialog and not the tooltip is not a violation of SC 1.4.13, as the SC doesn't dictate how the tooltip can be closed, just that it must be closable without moving focus away. ESC is just an example, any other key would be ok too.
Violation of 1.4.13 in your example would only be if there is no way to close the tooltip (and leave the dialog open). There is probably no other method in your example - but in my opinion all keys and key combinations would have to be checked to find it out...

[AccessibilityEnthusiastic]

@JAWS-test I tried with other key combinations but with the Esc key only I can close the tooltip.
But the entire dialog is getting closed here, instead of only the tooltip content. Can we consider it a failure here?

[JAWS-test]

Can we consider it a failure here?

Yes, because there is no way to close the tooltip

[bruce-usab]

That tooltip might count as providing input error. It seems rather long and detailed for a "tooltip".

[bruce-usab]

@AccessibilityEnthusiastic –1.4.13 does not require that the tooltip be dismissible by keyboard. That is a fine option for the author to support. The default ESC key behavior does not satisfy the Dissemble exception. Emphasis added below:

Dismissible: A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

With your example, since pressing the Escape key dismisses more than the additional content, no, that does not satisfy 1.4.13. But you cannot fail this UI behavior against this SC only just because of that. On Windows, Ctrl-F4 closes the current window — but that can not be used to meet 1.4.13!

You have not described the page in detail, but my guess is that one of the other exceptions are applicable.

[AccessibilityEnthusiastic]

@bruce-usab Please find the screenshot of the page

[awkawk]

I would call this a 2.1.1 error. The tooltip closes on escape key (https://react-spectrum.adobe.com/react-spectrum/Tooltip.html) and the issue is that the esc event is bubbling up to the parent dialog instead of being stopped at the tooltip. The result is an issue that impacts full keyboard access.

[patrickhlauke]

Do we know for sure that the Esc actually closes the tooltip, before closing the dialog? It may well be that there's actually no explicit tooltip closing behaviour implemented, and the lack of it is masked by the fact that the dialog is closed on Esc (in which case I would say that is a 1.4.13 failure only).

EDIT: ah, I see that example screenshot was from an Adobe property, so assuming they do use react-spectrum, then I'll go with Andrew's assessment there

[bruce-usab]

I cannot discern the hover behavior from the screenshot.

The tooltip appears on Dialog/Modal for the button.

Which is the button? The question mark? I assume the tooltip in question is the white text on dark grey background. Was this pop-up caused by on keyboard focus or mouse over? It looks non-modal to me, so if you can work the input via keyboard and tab to the next field that does not fail 1.4.13. If a mouse pointer hover pop-up, then try to move the mouse into the pop-up text. If it stays up, that is a pass.

Glad to have @awkawk in the thread! He will know the product behavior, and if there is a miss against one of the SC.

Edit to mention that the react-spectrum tooltips from the page Andrew provided all pass 1.4.13. On that page, the Esc key works fine too! But @AccessibilityEnthusiastic is using a input field, and if Andrew thing there is a bug, I believe him!

[awkawk]

@patrickhlauke We do run into situations where a non-standard component is used, so it is possible that is the situation here. @bruce-usab the component in question is the "tooltip" component, which can be applied to different controls. Our interpretation on this is that this could be just one bug (keyboard behavior issue against 2.1.1 due to the event bubbling that closes the dialog when you only need to escape the tooltip) or one bug that masks a second one (how can you be sure that the tooltip is closed when the whole dialog closes first?). Either way, we would record this as one issue, document the correct compound behavior that needs to occur when fixed, and that would cover it.