Wayfair's Keyboard Trap Exposes a Clause Most WCAG Guides Skip

Only 1 in 10 simplified WCAG re-interpretations mentions the clause in Success Criterion 2.1.1 Keyboard that bars "specific timings for individual keystrokes" — and that omission has a real-world cost, because Wayfair's site is failing it right now.

The normative text of SC 2.1.1 (Level A, WCAG 2.2) reads: "All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints."

Most plain-English rewrites of the criterion stop at "make it work with a keyboard." Some add keyboard-like devices. The author of the source post, an accessibility practitioner, counted ten simplified takes and found just one that acknowledged the timings language.

What does "specific timings" actually mean?

The W3C's Understanding page for SC 2.1.1 spells it out:

Examples of "specific timings for individual keystrokes" include situations where a user would be required to repeat or execute multiple keystrokes within a short period of time or where a key must be held down for an extended period before the keystroke is registered.

So a control that only responds if you hold a key down — or tap fast enough — fails Level A. It's rare to encounter such an interface, which may explain why the re-framings skip it: their authors may never have seen one.

Until now. The trigger for the post was an attempt to open a Wayfair link in a new tab while already browsing Wayfair. The author recorded the encounter: a human-checking, bot-affirming interstitial that demanded timed keyboard interaction before the page would load. The desk on the other side of that wall never got bought. The tab got closed.

How did practitioners react?

When the author posted a static screenshot and grumbled about it on Mastodon and Bluesky, the responses mapped the gap in collective knowledge:

• Scott O'Hara correctly guessed the behavior and named the 2.1.1 violation;
• BrainDouche said they were surprised to see it in the wild;
• Curtiss Grymala and another user, Joe, reported hitting the same wall — Joe the week prior.

Offline, the author asked peers to name which Success Criteria the pattern failed. Nobody named 2.1.1. On prompting, two reasons surfaced: the failure mode is rare enough to overlook, and several were relying on non-W3C resources as their sole WCAG reference.

That second reason is the one with legs. As Eric Eggert has argued, WCAG being hard to read becomes a self-fulfilling prophecy if accessibility workers don't read it — and leaning on non-normative third-party re-imaginings compounds the problem.

Does Wayfair know?

Probably not. Wayfair's published accessibility statement makes no concrete promises, so there's little signal about how motivated the company or its vendors are to fix it. The author declined to itemize the other WCAG failures of the same button, framing further free labor for a non-committed retailer as a bad trade.

The recap, in the author's own four points:

• SC 2.1.1 Keyboard has a clause about holding down keys;
• most simplified revisionist takes on WCAG miss that;
• if you use one that misses it, maybe stop using it;
• also don't be a Wayfair.

The wider lesson is procedural, not just about one retailer: audit your references against the normative text, because the clause nobody paraphrased is the one that failed on a major e-commerce site this month.