Add two notes/clarifications to 2.1.1/2.1.3 understanding

[patrickhlauke]

Add clarifications about 2.1.1 and what it specifically does not currently require, normatively.

Cross-reference to the original discussion a while ago #857

Related discussion #872

[patrickhlauke]

@alastc any chance of getting this onto some survey, maybe for the WCAG 2.0/2.1 subgroup? (only asking because the same uncertainty reared its head in the discussion for #2069 again)

[bruce-usab]

Is it worth mentioning that simple search fields (e.g., the Google homepage) routinely do not require an explicit/separate submit button — and those can be accessible?

[patrickhlauke]

@bruce-usab added a relevant example to the 2.1.1 understanding doc (the 2.1.3 understanding seems to have no examples at all, so i chose not to also add it there as it felt a bit too specific)

[JAWS-test]

Perhaps the question could still be answered whether it is a violation if the button can neither be activated with Enter or Space, but e.g. only with Alt+S - i.e. completely unexpected and not noticeable that an accesskey must be used.

[patrickhlauke]

@JAWS-test the answer to that is already implicit, but fine, added an extra parenthetical to the note

[JAWS-test]

@patrickhlauke

Thank you for the addition. Wouldn't it be useful to include a note that it is useful to follow the platform conventions though.

[patrickhlauke]

Any news on this @alastc ?

[mraccess77]

Created two PRs #3670 and #3669 to amend this PR to clarify that normatively accepting any custom key or custom key combination to satisfy 2.1.1 and 2.1.3 would fail assistive technology users (like switch users) relying on the keyboard interface.

In the past I thought the group had discussed failing lack of support for "click" events when keyboard interface support was provided might be an SC 4.1.2 issue.

[patrickhlauke]

accepting any custom key or custom key combination to satisfy 2.1.1 and 2.1.3 would fail assistive technology users (like switch users) relying on the keyboard interface.

would it though? do we know for sure? and conversely then, is there a list of "safe" key combinations that DO work for AT users? how do switch etc users operate things that require cursor key interactions, pressing Esc to close things, etc? seems a fairly broad (but then weirdly handwavy) statement to say "if you don't follow standards (which we can't actually document/tell you about) then you fail"

[patrickhlauke]

In the past I thought the group had discussed failing lack of support for "click" events when keyboard interface support was provided might be an SC 4.1.2 issue.

i think that discussion was part of some early WCAG 3 musings about what gaps there are in terms of input support (in general) in WCAG 2.x ... I may be wrong though (biting my tongue hard not to blurt out "accessibility supported", as that's just deferring to another handwavy concept)

[detlevhfischer]

do switch etc users operate things that require cursor key interactions, pressing Esc to close things, etc?

Would be interesting to research. But even when some elements should prove problematic in general, that does not mean that 99% (?) of user interface controls out there (links, buttons, checkboxes etc) should not be required to be built in a way that they support the common forms of activation.

[patrickhlauke]

normatively define "common forms of interaction", then normatively define "operable" to mean "must use those defined common forms of interaction"

[bruce-usab]

On call 2/3 (among other discussion) @detlevhfischer suggesting borrowing from 1.1.1 test exception.

If non-text content is a test or exercise that would be invalid if presented in text, then text alternatives at least provide descriptive identification of the non-text content.

[alastc]

Summary:

• The new note is correct to the normative language.
• There is concern that it appears to open a loophole, or draw attention to not-good implementations.
• It might be possible to add something to Labels & Instructions to require/encourage documentation for odd keyboard short-cuts.
• It doesn't seem likely that people put the effort into making something keyboard accessible, and then use weird commands, and not provide documentation.
• Note that 2.1.2 does specifically say that instructions are provided, but 2.1.1 does not.

[mraccess77]

In the past I thought the group had discussed failing lack of support for "click" events when keyboard interface support was provided might be an SC 4.1.2 issue.

i think that discussion was part of some early WCAG 3 musings about what gaps there are in terms of input support (in general) in WCAG 2.x ... I may be wrong though (biting my tongue hard not to blurt out "accessibility supported", as that's just deferring to another handwavy concept)

To be clear - I'm not referring to pointer input - but programmatic activation as 4.1.2 indicates "and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies."

I relate this to the switch control discussion as screen readers may use programmatic methods to activate controls in virtual cursor/browse mode.

[patrickhlauke]

To be clear - I'm not referring to pointer input

I understand, and I believe that (going beyond "it's either a pointer or a keyboard?") was part of the discussion for inputs in general we had a while ago in the WCAG 3 context

[alastc]

Next step - Detlev agreed to continue with this one, effectively dropping the objection, so we can merge once the review period is over.

[mbgower]

Next step - Detlev agreed to continue with this one, effectively dropping the objection, so we can merge once the review period is over.

@detlevhfischer I'd like to see us also include some wording around documenting unconventional keyboard interactions, so please incorporate into your next changes.

[mbgower]

@detlevhfischer and @WilcoFiers although it appears to me that all your comments have been dealt with, the system still thinks there is something unresolved from your reviews, so I've triggered a rereview so that I can merge.
LMK if you have questions!

[WilcoFiers]

"Keyboard interface" seems a little odd. An on screen keyboard is an interface, but I wouldn't call the physical device an interface. I can live with it though.

Approved in meeting.

[GreggVan]

"Keyboard interface" seems a little odd. An on screen keyboard is an interface, but I wouldn't call the physical device an interface. I can live with it though.

Hi Wilco - the keyboard is not the "interface" referred to. What is referred to is that the software does not get input from the keyboard -- it gets its "keyboard input" from the software API/ interface to the software. The actual 'keyboard input' it gets from that "keyboard interface" may come from a physical keyboard, and onscreen keyboard, a morse code program, a speech input system etc. Hence we don't require that software work with keyboards -- but with the "keyboard interface (API) that the software gets "keystrokes" from.

Make sense now?

[CityMouse]

recommendation:
Change "Keyboard interface" to "Keyboard input"

reason for recommendation: for consistency (w/ pointer) and to reduce confusion
It would would address display rendering of keyboard & hardware keyboard]

[mbgower]

@CityMouse This PR was merged before your comment. If you'd like to see this become "Keyboard interface", please open a new issue so that it gets tracked/discussed. Feel free to cross reference this PR.

[detlevhfischer]

This looks like what was agreed in the Friday call. While I would personally prefer to leave out the bit "(or even a completely custom key or key combination)" because I am not a fan of broadcasting loopholes, I accept the text.
Also, I would prefer "keyboard interface" as well since this makes use cases such as switch, and potential issues of that group with the normative text, clearer.

[patrickhlauke]

wasn't "keyboard interface" chosen because it matches the actual normative wording of the SC? i originally just had "keyboard" and "keyboard users" etc, but we tweaked it to be more closely aligned with the normative text....

(sorry, a roundabout way of saying: so discussions on changing it to "Keyboard input" would mean we're out of sync with the normative SC text, unless the suggestion here was to ALSO change the normative text which of course would be a non-starter at this late stage)

[detlevhfischer]

wasn't "keyboard interface" chosen because it matches the actual normative wording of the SC?

If it was, I am happy with that. Some places in the PR just have keyboard and not keyboard interface, but that may be OK.