Add to 2.1.1 understanding if keyboard interactions that don't work when AT is enabled fail or pass (was: Add to understanding of 2.1.1 a paragraph about mobile)

[DavidMacDonald]

There is a proposed SC for WCAG 2.1 that keyboard should work when AT is running. https://github.com/w3c/wcag21/issues/62 It is intended to address mobile AT running on Talkback and an iPone. However, this is already required in WCAG 2.0 and I'm nervous that adding a new SC to 2.1 will undermine the requirements of the current 2.1.1 ans the accessibility support conformance requirement.

Therefore, I'm proposing an update to the understanding document for WCAG 2.0 SC 2.1.1. If approved I can create the pull request.

Add to understanding

All functions available by keyboard are still available by keyboard after accessibility-supported assistive technology that remaps keystrokes is turned on. It is not always possible for users to activate arbitrary keys on a keyboard, as these may be reserved for commands to operate an assistive technology. Assistive technologies may intercept key presses before they reach the content (e.g. JavaScript on a webpage), except in very specific circumstances (such as when a text entry field receives focus).

As such, authors must not assume that users are able to successfully activate any particular key controls arbitrarily. This success criteria would apply to the assistive technology that is accessibility-supported and remaps the keyboard.

Add to Benefits

This ensures that all users can operate the functionality when the keyboard is used with the assistive technology.

[marcjohlic]

From @mbgower pulled from w3c/wcag21#62

Just a note that when/if we get around to modifying 2.1.1 for matters already discussed here and in places like #63 (Touch with AT) and #67 (Device Sensors) , some language around avoiding keydown and mousedown can be incorporated into 2.1.1, and we should consider creating some Failure Techniques. See the Testability and Techniques sections of #59 Pointer as a starting point.

[alastc]

Hi @DavidMacDonald, given that the WCAG 2.1 SC Character Key Shortcuts requires the ability to re-map or turn off shortcuts, is this needed? If not, please close. If it is needed, I didn't quite get-it...

[patrickhlauke]

this is not so much about remapping, but rather about - to give it a very specific example - pages that listen to keyboard events but then fail to do things like adding role="application" or correct roles to controls, meaning that when AT is running, custom keyboard interactions (think for instance use of cursor keys) just don't work since those keys are then consumed by the AT. a related aspect (e.g. ignoring/not registering keyboard listeners or just assuming it will all just be touch when it's on a mobile/tablet is covered by concurrent input mechanisms SC now, so no need to go over that aspect specifically)

[alastc]

It sounds like a technique under 4.1.2 would be suitable for that example. In terms of the content, would an author need to change the scripting/events, or is it just the role aspect that needs filling in?

[patrickhlauke]

will be working on a small proof of concept/example, but more fundamentally, I believe the question here is: if the author missed out on adding something like role="application" to their custom control which, say, works using cursor keys, but not when AT on windows is running because there the cursor keys are being ingested and processed directly by AT ... yes, this would likely be failure under 4.1.2 for missing out the correct/necessary role, but does it also fail 2.1.1 Keyboard?

[patrickhlauke]

or, similarly: say an author creates a nice tab panel interface that does all the right things (tablist takes one focus stop, user then uses cursor keys to switch between tabs), but forgets the right roles so when AT is running, the cursor keys only move the screen reader's reading cursor, rather than triggering the correct tab behavior. it fails 4.1.2 for missing the role, but do folks also mark this as a failure of 2.1.1? historically, I have noted this only as a 4.1.2 failure, but always had a nagging feeling that it also fails 2.1.1

[mbgower]

I sorted by the oldest issues and came up with this one.

I'd like to restart the discussion using one scenario:

1. An application works completely fine by keyboard when no AT is running.
2. With AT running the keyboard no longer functions properly.

Starting with the assumption that this is not a bug in the AT (which can be an explanation), does the user report this as a failure of:

1. 2.1.1 Keyboard
2. 4.1.2 Name, Role, Value, OR
3. Accessibility-supported OR
4. Something else?

The obvious challenge failing it with 2.1.1 is that we've already established in our scenario that "All functionality of the content is operable through a keyboard interface." So it seems problematic to fail it there.

The challenge with failing it against 4.1.2 is that role does not designate keyboard interaction (definitely not for non-native elements).

While accessibility-supported is a conformance requirement, that doesn't really solve how to report it, since that is not a numbered SC. Is there something else?

I think David's suggestion is to add indication in the Understanding document that this DOES represent a failure of 2.1.1 Keyboard. It is one approach.

[patrickhlauke]

i think we need to be a bit more specific in how/why it's not working with AT enabled. is it because it perhaps has an incorrect role (as role does determine, in Windows ATs for instance, which keyboard press is passed on to the page and which is consumed by the AT itself)? in those cases, it's a 4.1.2 failure (since now we have the "appropriate" wording in the understanding)

if it's because it's using an unorthodox keyboard interaction, we go right back to the fact that keyboard interactions aren't standardised as such, so we can't unambiguously change 2.1.1 to mandate "standard" keyboard controls, since there is no standard. i would lean more towards an accessibility-supported argument

[mbgower]

@patrickhlauke

Where it happens as a result of a role misalignment, then yep, we can probably fail against 4.1.2. Although in some way that line of reasoning loops back to your second comment ("if it's because it's using an unorthodox keyboard interaction, we go right back to the fact that keyboard interactions aren't standardised as such"). We might need to spend a bit more time focusing on this because I do think maybe we have a bit more muscle here than we think. To make the most obvious example, if someone created a Select element that overrode the user agent operability and made it not traverse the options with arrows but had each option be in the tab order, would anyone really defend that as just another author interaction decision, with no scope to fail it against 2.1.1? I think there are clearly key press requirements for the standard HTML elements, at a minimum. I also suspect we could extend that based on some user agent conventions (think about how one navigates in a date input's calendar grid, for example).

But in regard to your second paragraph comment, "if it's because it's using an unorthodox keyboard interaction", please look at my starting scenario:

An application works completely fine by keyboard when no AT is running. With AT running the keyboard no longer functions properly.

[patrickhlauke]

I do think maybe we have a bit more muscle here than we think. To make the most obvious example, if someone created a Select element that overrode the user agent operability and made it not traverse the options with arrows but had each option be in the tab order, would anyone really defend that as just another author interaction decision, with no scope to fail it against 2.1.1? I think there are clearly key press requirements for the standard HTML elements, at a minimum. I also suspect we could extend that based on some user agent conventions (think about how one navigates in a date input's calendar grid, for example).

Really not a fan of this, and it would now introduce new normative requirements by the understanding backdoor that did not previously exist.

[patrickhlauke]

think about how one navigates in a date input's calendar grid, for example

which does not even exist on certain other platforms, like iOS/Android's take giving tumbler spinners instead

there are clearly key press requirements for the standard HTML elements, at a minimum

however, they're not normatively documented anywhere (not even in the HTML spec). and then ... what happens then when it's a custom control that doesn't exist in HTML? would you say that then is exempt (which obviously would not make sense)? or making it a failure not to follow ARIA APG suggestions of keyboard interactions (blessing APG as "the standard")?

[mbgower]

So, just to play Devil's advocate here, if a user reaches a text input, and instead of keys on a keyboard putting in their assigned values, the author inputs something completely different for each key press, we wouldn't flag this under 2.1.1?

If on another page, an author inverts the arrow key movement, so that right goes left and vice versa, we wouldn't flag this under 2.1.1?

If a user reaches a page that does not respond to Tab or Arrow Key for navigation, but arbitrarily causes that to happen when some random key or key combination was pressed, that we wouldn't report that under 2.1.1?

[patrickhlauke]

under the current wording of the SC ... yes, those would all be technically passes, but obviously horrible UX. unless we want to introduce new normative requirements by the backdoor in the understanding document by saying "of course, when we said 'through a keyboard interface' back in 2000, we implicitly meant 'and using standard keys even though those aren't normatively defined anywhere' ..."