Clarifying No Keyboard Traps (SC 2.1.2)

[njeleniauskas]

I was recently reviewing text formatting experiences from a keyboard user's perspective, and how they might get trapped when indentation is enabled — for example what users can experience in Google Docs or code editors. And this exploration sparked some questions about the language found in Success Criterion 2.1.2 No Keyboard Trap that I hoped to get some clarification on.

Specifically, I realized that SC 2.1.2 lacks a testable definition for what a "standard exit method" is. And this also affects our understanding of what situations require "advising the user", and even, what techniques constitute "advising."

My assumption is that a standard exit method is a key that has a consistent function (cross app/OSes), and thus would include Tab, arrow keys, and Escape? But would this also include OS keys as well (Win/Cmd/Super)? At present, its not clear what keys are considered "standard" and whether standard is intended to be locally or globally scoped (would OS keys or F6 apply (if F6 was consistent of course), or even screen reader navigational keys for those situations?).

Related to this is understanding what constitutes "advising the user." My guess is that intent here is the following: if a non-standard method is used that the user is immediately and directly informed of the exit method at least once within their entire experience. But again, this both depends on what a non-standard method is, and what is considered an acceptable advising technique. The guideline and supplementary docs are a little opaque about this.

As an example, are indirect advising methods considered acceptable? As in, the way keyboard shortcuts are communicated to users in Google Docs? Or is the word advising supposed to also mean "directly?"

Thanks for clarifying these questions and the intent of the guideline.