SCR39 example (SC 1.4.13 content/hover) needs improving

[JAWS-test]

The Example of a pop-over on hover and focus for SCR39: Making content on focus or hover hoverable, dismissible, and persistent has the following problems:

• Focus outline is displayed not only around link, but around link and tooltip. Cause: Tooltip is the child element of the link.
• Tooltips are output by the screenreader as part of the label. With the Screenreader, labeling and tooltip are indistinguishable. The output of the tooltips cannot be suppressed. The screenreader outputs the role "Link" after the tooltip has been output. It would be better if the tooltip is output as a description. Cause: Tooltip is the child element of the link. Recommendation: Link should refer to tooltip via aria-describedby.
• The tooltip text cannot be selected and copied with the mouse. Cause: Tooltip is the child element of the link.
• If tooltips are inside a pop-up, there may be problems with ESC closing the pop-up (1.4.13 Content on Hover or Focus - dismissable and persistent clarification #914).
• The JS code is written so that it only works for one tooltip per page.
• The example does not work in IE 11 (tooltips are not shown)

I suggest that the APG tooltip example be used for orientation

[detlevhfischer]

I put this together and I am aware of the defects (I am not an accomplished scripter). It was never meant to become an official example. I have implored others to provide better examples. Somehow the example was used nevertheless, I don't know why. I would be glad to see this replaced ASAP.

[alastc]

I don't think the APG example would qualify, it blocks content and can't be dismissed. However, it would be good to improve the example. Just need someone to step up and do it...

[JAWS-test]

it blocks content and can't be dismissed

The tooltips can be closed with ESC as required by SC 1.4.13.

[patrickhlauke]

it blocks content and can't be dismissed

can be dismissed with Esc

[detlevhfischer]

Looks like a good candidate. I note that on MacOS 10.15.1 / Safari 13.0.3, calling up the tooltips with mouse hover, ESC (touch bar ESC) does not close the tooltip. ESC does, however start to work also after bringing up the element on hover as soon as the controls have been focused once by keyboard. Not sure what is happening here...

[patrickhlauke]

ah, i stupidly didn't check the dismissability when moving to it with the mouse. in that case agree, this currently fails that aspect - can't trigger it via mouse and THEN close it with Esc without moving the mouse. note that this is causing implementers quite some grief, from various discussions recently, as to satisfy this, you have to essentially register a key listener to the whole of the page when the tooltip gets shown as a result of hover, which gets complex if you're already in, say, a modal dialog or similar which also needs to react to Esc. it's a non-trivial ask, JavaScript-wise.

however start to work also with hover as soon as the controls have been focused once by keyboard. Not sure what is happening here...

the key listener is on the button. if focus is on the button, then even if you triggered the tooltip with mouse, pressing Esc goes to the event listener on the button which then closes the tooltip.

[JAWS-test]

calling up the tooltips with mouse hover, ESC (touch bar ESC) does not close the tooltip. ESC does, however start to work also after bringing up the element on hover as soon as the controls have been focused once by keyboard

That's not really true. The tooltips that are displayed by hover can only not be closed with ESC if the focus is not on the page. This is the case with codepen, because the test page is integrated via iFrame. If the focus is somewhere in the iFrame, the hover tooltips are also closed correctly with ESC. For the WCAG page, however, the example would be sufficient because it can be implemented without iFrame. A warning could be inserted, that for the use in iFrames adaptation at the JS has to be done.

[alastc]

Ah, it looks like 'esc' didn't work because of the frame/focus aspect, it would in a regular page.

If someone can pull that example (or something similar) into an example page, we can get that replaced.

[patrickhlauke]

this does bring up an interesting conundrum...if a page uses something like an iframe, and in that there's a tooltip or similar...how is a site supposed to handle the scenario above (user moved with the mouse without setting focus inside the iframe)? and who fails...the main site or the iframed content? (noting an iframe can't attach a key handler on its parent/host page)

[mraccess77]

It seems like folks are saying it's a requirement that esc works when the trigger/additional content is not focused - if this is what the group thinks we should update the understanding document to be clear on this point - because it's not clear and the default assumption would be that escape only had to work when the trigger or additional content was focused.

[alastc]

@patrickhlauke wrote:

if a page uses something like an iframe... who fails.

I think the 'page' (as defined) has to be correct, a parent page can't fail for an inner iframe, and vice versa. There will be some oddities, but I can't see another way of dealing with that.

@mraccess77 wrote:

It seems like folks are saying it's a requirement that esc works when the trigger/additional content is not focused

I thought that was the logical conclusion of the 'dismissable' bullet, considering that you generally would not have focused on something you hover over:

A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus

A few options have been muted for dismissing the new content after a hover trigger, but 'esc' has been the main realistic choice so far, including in the SCR39 example we're discussing.

[alastc]

Also noting for @michael-n-cooper, the test part of technique scr39 is not being output by the build.

[JAWS-test]

and who fails...the main site or the iframed content?

The question sounds as if, according to the WCAG, an iframe does not belong to the side. I do not think so. A page includes all embedded elements such as images, videos, and iframes. If external content is included via the iFrame, "Statement of Partial Conformance - Third Party Content" can be used, with the exception of SC

• 1.4.2 - Audio Control,
• 2.1.2 - No Keyboard Trap,
• 2.3.1 - Three Flashes or Below Threshold, and
• 2.2.2 - Pause, Stop, Hide.

[patrickhlauke]

if I am the one that is creating/providing the content that other sites, or even my own site elsewhere, is pulling in via <iframe>, i have no way of ensuring that a key listener for Esc is added to the parent/owner document. so I have no way of ensuring that my content passes this SC in actual usage.

[JAWS-test]

i have no way of ensuring that a key listener for Esc is added to the parent/owner document.

I am aware of that. But that does not change the fact that according to WCAG the whole page including iFrames has to fulfill the SCs. That means, there is currently a SC that can not be technically met unless it is said that either iFrames or hover content is not allowed.

[awkawk]

@patrickhlauke This is what the Statement of Partial Conformance is for: https://www.w3.org/TR/WCAG21/#conformance-partial

So, I agree with @JAWS-test in that the iframe content is part of the whole page, however inconvenient that may be. :)

[JAWS-test]

The problem (that hover tooltips can not be closed with ESC) occurs not only with iFrames, but also when the focus is not on the page, but e.g. in the menu or the address bar of the browser or in another application. Perhaps the understanding of 1.4.13 should be added that closing with ESC can only work and is required only when the focus is on the page. The iFrame problem would, in my opinion, continue to exist.

[patrickhlauke]

however inconvenient that may be. :)

I'm not saying it's inconvenient, I'm saying it's likely not technically feasible for me to do anything about it even if i controlled both iframe and host page

[JAWS-test]

For these reasons, I would say that "Dismissable" should be achieved differently:

• for keyboard users with ESC
• for mouse users via ESC (if the focus is in the document) or via a close button (if the focus is not in the document)

See: #914

[patrickhlauke]

strictly though, having a close button would mean they need to move the pointer to the close button, which then defeats the point that they should be able to dismiss it without moving the pointer