Simplifying popup interference

Hello LVTF to be reckoned with,

>From today's call, I now *think* I understand the intentions behind the popup interference SC, and have tried to simplify the language down to a single sentence that covers 2 important scenarios:

1.       Popups can be very difficult or impossible to perceive if I am required to keep my pointer on the triggering content.  For example, a popup with a large amount of information that under magnification I need to pan, change zoom, etc., or a popup that I may want to get extra screen reader information from using mouse hover.  The solution is simply to not allow the popup to disappear while I have hover or focus on the popup.

2.       Poorly positioned popups can cover all or part of their original element, making it much more difficult to interact with because we keep triggering the popup, which is more likely under magnification or with low vision in general.  The solution is to always position off the original trigger.

The other situation we covered on the call is the problem of the pointer itself getting in the way of content, but I think we agreed on the call that dictating position is not the best approach given that user agents need to be involved and pointers may vary significantly from user to user (e.g. bottom right is a problem for a typical right-handed arrow, but the situation is different for a left-handed arrow or resizing pointers).

Did I miss anything?  Other comments?

If not, here's some simplified wording perhaps to restart the engine:

Popup Interference: Popup content does not render any of its triggering content invisible, and remains visible while pointer hover or focus is on the popup content.

And where we define popup as "becomes visible only on pointer hover or focus".

Critique away...

Steve

Received on Thursday, 20 July 2017 17:06:35 UTC