WCAG 3 parking lot considerations from 2.x

This is a place to list topics that are discovered from WCAG 2 issues that cannot be resolved inside the existing normative scope of WCAG 2.x and thus are consideration for the next version of WCAG.

General concepts

Alternative version

Keyboard documentation

As per https://github.com/w3c/wcag/pull/1642#pullrequestreview-1784175041 there is currently no requirement to document a non-conventional keyboard operation in WCAG. If it can be done by keyboard but a user cannot figure out, it is not a failure!

For WCAG 3, a requirement to document accessible methods/keyboard where they deviate from conventions (and maybe some establishments on conventions) should be included. It’s another of those situations where I do not believe it was the intent by authors of WCAG that a mysterious key should pass; rather, the assumption was keyboard operation would be not just Operable, but predictable and Understandable. In a word, Robust 🙂

2.1.2 does have that kind of caveat “...if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.”

2.2.1 also introduces the idea of ‘before encountered’. IMO WCAG 3 should introduce a notion of documentation within the current UI or some such wording to establish that the user does not need to spend effort figuring out how to operate.

Poor terminology to revise/avoid

WCAG 2.x could use an editorial pass to remove “trigger” words.

"Requires"

One example is “requires”, as a reader might easily infer it to mean “required” (or requirement for conformance). Example from 3.3.2:

"Labels or instructions are provided when content requires user input."

This use of “requires” is not intended to be read to mean that labels are only provided for fields that are marked as "required". The intent is that labels or instructions must be in place for each input field.