Keyboard operation with assistive technology: 2.1.1 or 4.1.2?

[JAWS-test]

If the keyboard operation is possible with a keyboard interface and without further assistive technology, but not with the keyboard and with assistive technology: Is this a violation of SC 2.1.1 or 4.1.2 ("states, properties, and values that can be set by the user can be programmatically set" - but the activation of a link is not the setting of a status, value or property ...)?

An example: Key event handlers are converted from assistive technology to click event handlers. If a page implements only the key event handler, the page is operable with the keyboard, but not if a screen reader is used additionally.

If other people think that this question is not sufficiently explained in the Understanding documents, the answer to this question should possibly be added to 2.1.1 and 4.1.2.

See: https://github.com/w3c/aria-practices/issues/1159

[mraccess77]

I would fail under 4.1.2.

[patrickhlauke]

admittedly though, that's not all that clear from the normative wording of 4.1.2 (the fact that a "value" can be "programmatically set" is not really a strong indication of "a button can be activated to trigger some functionality" or similar). while the understanding doc then mentions "activate", it's a bit vague nonetheless...

admittedly, i've been known to fail this sort of thing under 2.1.1 in the past. and in certain situations i'd argue there's still a bit of a loophole here in WCAG 2.1 in this respect.

[JAWS-test]

Shall we close the loophole? Any ideas?

[detlevhfischer]

We would also tend to fail such behaviour (works with kb, but stops working when Screenreader is turned on) under 2.1.1 although it gets tricky when it works in some UA/AT combos, giving us head-aches. In terms of the principles buckets, it seems more a robustness issue (aka "implementation not robust enough to work with kb when SR on"), but it seems somewhat ill-placed under 4.1.2.

[alastc]

Are there examples where something is coded to use keyboard events in a way we'd assume is reasonable but then doesn't work with AT? (Apart from touch-screen usage.)

The only examples I can think of are using very specific keyboard events that we'd generally fail under on-input, on-focus, and will often fail pointer-gestures or something else.

Is there a non-theoretical gap?

[JAWS-test]

This is not a theoretical question, but a problem that occurs very frequently in accessibility tests:

An example: Key event handlers are converted from assistive technology to click event handlers. If a page implements only the key event handler, the page is operable with the keyboard, but not if a screen reader is used additionally.

This concerns e.g. the screenreader JAWS and the activation of pseudo-buttons, links etc.. The click event handler for mouse users is sometimes not located at the element which the screen reader user focuses with the tab key and is therefore not triggered. If desired, I can create an example for such behavior at Codepen.

[alastc]

The click event handler for mouse users is sometimes not located at the element which the screen reader user focuses with the tab key

In a way that affects people using Jaws but not affecting people using the keyboard without Jaws? If so, please do point to an example please.

[JAWS-test]

In a way that affects people using Jaws but not affecting people using the keyboard without Jaws?

Yes. I will create an example

[JAWS-test]

If so, please do point to an example please.

https://codepen.io/jaws-test/pen/OJLeJGP

I would like to emphasize that the behavior shown in the example is not uncommon.

I tested with JAWS 2019 + IE 11, Chrome and Firefox and with Talkback + Chrome.

In JAWS, one can set whether key events should be converted to click events. The default setting is to convert key events to click events.

With NVDA I can activate both buttons in this example

[patrickhlauke]

@alastc

Are there examples where something is coded to use keyboard events in a way we'd assume is reasonable but then doesn't work with AT? (Apart from touch-screen usage.)

there's no "reasonableness" clause anywhere though, so define "reasonable"...

a site could do something odd like

<div role="button" tabindex="0" onkeypress="if(event.keyCode == 32) { ... }">button</div>

(say it's a "keyboard alternative" to some mouse behavior defined elsewhere). this nominally passes 2.1.1, and i don't see how this could be flagged as failing on-input, on-focus, or pointer gesture...and still, it won't work with AT running as they'll consume the SPACE press.

the "reasonable" thing feels like the usual "yeah but devs wouldn't do that, so don't need an SC to cover that" wiggle.

similarly, the same can happen with things that nominally work for mouse and keyboard, but not with touch+AT - there's no real SC you can file that against as a real failure (we've, in the past, filed those still under 2.1.1 under the rationale that touch+AT is a sort of linear/keyboard-like way of navigating, but that's always been a hack)