Re: [Understanding and Techniques Feedback] SC 2.1.1, Keyboard

Hi Casey,

It is correct to say that scenario isn’t a failure. It is not desirable, but that doesn’t make it a failure.

WCAG is intended to be a baseline, with strong hints about what “good” accessibility is.

For scenarios such as non-standard controls, there is a wide range of things that could be good, ok, poor, or utterly confusing. It’s very hard to create an objective (i.e. normative) rule about that type of thing, so in general WCAG will aim to prevent the definitely (and objectively)  inaccessible, and guide towards good.

If it helps, there are several discussions on this topic:
https://github.com/w3c/wcag/issues/857
https://github.com/w3c/wcag3/issues/188
https://github.com/w3c/wcag/pull/1642

Also, WCAG 3 is going in a slightly different direction where it includes requirements like WCAG 2, then also has requirements or assertions you can meet to score more or get to a higher level of conformance for things like using standard keyboard controls.

Kind regards,

-Alastair


From: Casey Hickey <casey.hickey@cortland.edu>
Date: Tuesday, 21 October 2025 at 07:43
To: public-agwg-comments@w3.org <public-agwg-comments@w3.org>
Subject: [Understanding and Techniques Feedback] SC 2.1.1, Keyboard

You don't often get email from casey.hickey@cortland.edu. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>
Hello w3,

I’m writing with feedback on SC 2.1.1, Keyboard<https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html#intent>. I’d like to comment on the following text:

Note

Platforms and user agents usually have conventions for how web content or applications are controlled with a keyboard interface. If content does not follow the platform/user agent conventions it may be difficult to use, as users will need to learn different interaction methods. As a best practice, content should follow the platform/user agent conventions. However, deviating from these conventions does not fail the normative requirement of this success criterion.

I’ve encountered several custom elements lately where arrow keys are used to expand/open content. For example, an <input> with type=“text” that a user cannot type into, and where the user must open a date picker using the down arrow key while focused on the <input>. I’d assert that using the down arrow key to access the date picker is not an apparent interaction method, especially if the user is not informed of that behavior.

In response to the scenario I just described, a developer could point to the text I copied above and say “WCAG says this isn’t a failure.” Is that the intended outcome here? I understand that having to get used to a custom interaction method is not an accessibility barrier. But what if the different interaction method is so unintuitive that some users won’t know what to do? I’d appreciate a change to this note stating that a custom interaction method could constitute a failure of the normative requirement if the method is not apparent.

Thanks for any thoughts on this,

Casey Hickey