RE: Best approach for meeting Success Criterion 1.4.13 Content on Hover or Focus via ESC key

Everything has a scalability limit of course….

To avoid iterating, you might only listen when one of those things is currently being hovered.  Then you don’t have to iterate since you know which one is being hovered.

I can try to put that code together and clean it up.

Steve

From: Detlev Fischer <detlev.fischer@testkreis.de>
Sent: Tuesday, August 28, 2018 4:30 PM
To: Repsher (US), Stephen J <stephen.j.repsher@boeing.com>
Cc: Alastair Campbell <acampbell@nomensa.com>; WCAG group <w3c-wai-gl@w3.org>
Subject: Re: Best approach for meeting Success Criterion 1.4.13 Content on Hover or Focus via ESC key

Hi Steve,
Thanks for the quick mockup!
Would this scale well if you have a page with, say, 100 in-page links which show pop-over explanations /expanded acronyms and so on?
I guess you would then have to iterate for all elements with class .stuff - not ideal performance-wise, I guess. But good to see it is doable nevertheless.
I just wonder what a Positive Technique should look like - would it suggest to register elements that have popped up in one variable so the element registered as visible would be closed on ESC? (Alastair mentioned something along those lines.) Or would we propose a more generic approach based on your example (with iteration)?

Detlev


Am 28.08.2018 um 20:57 schrieb Repsher (US), Stephen J <stephen.j.repsher@boeing.com<mailto:stephen.j.repsher@boeing.com>>:

Maybe I’m misunderstanding, but as I said in the meeting I’m not sure why the conclusion is being drawn that you can’t use the CSS hover selector to show content and still pass.  Just playing around, here’s a quick test page (pardon the lack of elegance):

<doctype html>
<html>
<head>
<style>
.stuff {display:none;}
.trigger:hover .stuff {display:block;}
</style>
<script>
document.onkeydown = function(evt) {
    evt = evt || window.event;
    var isEscape = false;
    if ("key" in evt) {
        isEscape = (evt.key == "Escape" || evt.key == "Esc");
    } else {
        isEscape = (evt.keyCode == 27);
    }
    if (isEscape) {
        document.getElementsByClassName("stuff")[0].style.display = "none";
    }
};

function resetDisplay() {
document.getElementsByClassName("stuff")[0].style.display = "";
};
</script>
</head>
<body>
<h1>Test Page</h1>
<div class="trigger" onmouseout="resetDisplay()">
<p>Hover me then press ESC</p>
<p class="stuff">Get rid of me by pressing ESC without moving your mouse</p>
</div>
</body>
</html>

In this case the listener is always active but it could be restricted to only when the trigger has hover.  Things get more complicated if the page is tracking lots of other keyboard events, but still feasible.

DISCLAIMER: I’m swinging for the fence coming right off the bench so go easy on me if it’s a big miss!

Steve

From: Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>>
Sent: Tuesday, August 28, 2018 10:30 AM
To: Detlev Fischer <detlev.fischer@testkreis.de<mailto:detlev.fischer@testkreis.de>>
Cc: WCAG group <w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>>
Subject: Re: Best approach for meeting Success Criterion 1.4.13 Content on Hover or Focus via ESC key

Hi Detlev,

I’m not sure what you’re looking for from the group or Steve, where your article said:
“One consequence could be that content on hover or focus should be triggered via scripts rather than via CSS pseudo-classes to prevent a situation where the content pops up again straight after dismissal.”

I think that is a fairly straightforward: If you use only CSS to create content on hover (or focus), then it must be for input errors or not replace other content.

You could theoretically create a keyboard event that hides any content shown on hover, but it would be very difficult to do in a reasonable way.

Given the difficulty they can cause, the idea was that people would avoid this or put the necessary work in to do it well (which includes JS).

-Alastair

Received on Tuesday, 28 August 2018 20:38:01 UTC