search

w3c / wcag

Web Content Accessibility Guidelines
https://w3c.github.io/wcag/guidelines/22/
Other
1.13k stars 257 forks source link

SCR39 example (SC 1.4.13 content/hover) needs improving #915

Open JAWS-test opened 5 years ago

JAWS-test commented 5 years ago

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:

I suggest that the APG tooltip example be used for orientation

detlevhfischer commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

it blocks content and can't be dismissed

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

patrickhlauke commented 4 years ago

it blocks content and can't be dismissed

can be dismissed with Esc

detlevhfischer commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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

JAWS-test commented 4 years ago

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

patrickhlauke commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

See: https://github.com/w3c/wcag/issues/914

patrickhlauke commented 4 years ago

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