W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2018

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

From: Repsher (US), Stephen J <stephen.j.repsher@boeing.com>
Date: Tue, 28 Aug 2018 18:57:33 +0000
To: Alastair Campbell <acampbell@nomensa.com>, Detlev Fischer <detlev.fischer@testkreis.de>
CC: WCAG group <w3c-wai-gl@w3.org>
Message-ID: <6230379dfb794504b158fed5e86b36ee@XCH15-08-08.nw.nos.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>
.stuff {display:none;}
.trigger:hover .stuff {display:block;}
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 = "";
<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>

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!


From: Alastair Campbell <acampbell@nomensa.com>
Sent: Tuesday, August 28, 2018 10:30 AM
To: Detlev Fischer <detlev.fischer@testkreis.de>
Cc: 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 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).


Received on Tuesday, 28 August 2018 18:58:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 28 August 2018 18:58:04 UTC