The 2.1.1 “specific timings” Clause

Many simplified, intro, or “plain-English” WCAG re-interpretations frame Success Criterion 2.1.1 Keyboard as ensuring a control or widget or thing can be operated with a keyboard. Some go further and also ask you to consider keyboard-like devices.

Very few (I counted 1 out of 10) pay attention to the part mentioning timings (emphasis mine):

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.

This might be because it’s rare to find a keyboard interface that requires the user to do a specific keystroke for a specific time. The authors of these simplified re-framings may have never even seen one before.

The W3C’s 2.1.1 Understanding page explains what specific timings means:

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.

This is in my head because of an experience I had at Wayfair:

When I posted a static image and grumped about this on the socials (Masto, Bluesky), Scott rightly guessed the behavior and noted the 2.1.1 violation. BrainDouche was surprised to see this in the wild. It’s an obvious problem regardless of the SC, as Curtiss Grymala experienced and Joe had also noted the week prior.

I got feedback in real life as folks named the assorted SCs this failed (people play weird games; don’t judge). None of them named 2.1.1, however (ok, maybe judge). On prompting, it was a combination of overlooking such a rare failure and using non-W3C resources as their sole WCAG reference.

I get that WCAG is not an easy read, but if you’re going to do the job, then as Eric Eggert points out, you have to do the work. Don’t rely on non-W3C non-normative re-imaginings of WCAG (he also has opinions on that).

I doubt Wayfair is aware of the WCAG violation here. Wayfair’s accessibility statement makes no promises, so I’m not sure how motivated it or its vendors are.

I could lay out a case for the potential loss of revenue, as I did for IndieGoGo. Or I could not give free labor to point out the other ways that human-blocking bot-affirming Wayfair button fails under WCAG.

To recap:

• 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.