Clarification needed: dragging movements and on screen keyboards

[scottaohara]

The following paragraph from the dragging movement SC has come up a number of times in queries to me that I think it is worth bringing to the WG's attention.

This requirement is separate from keyboard accessibility because people using a touch screen device may not use a physical keyboard. Keyboard specific interactions such as tabbing or arrow keys may not be possible when encountering a drag and drop control. Note, however, that providing a text input can be an acceptable single-pointer alternative to dragging. For example, an input beside a slider could allow any user to enter a precise value for the slider. In such a situation, the on-screen keyboard that appears for touch users offers a single-pointer means of entering an alphanumeric value.

Specifically, the paragraph is being interpreted as a bit of double speak. Where it initially states that the SC is separate from keyboard accessibility - but then later states that someone could use the mobile on screen keyboard to enter a value into a text field.

This has raised the question as to why on screen keyboards, in general, cannot be used to pass this SC. This question has been particularly raised when reviewing native/web desktop applications where the primary action of someone using the application would largely revolve around needing to be able to use their keyboard (or if they cannot use a keyboard, voice control software which would allow someone to speak keyboard commands if needed. E.g., "press left X times" to move something).

I can imagine a few responses to these queries (but me assuming answers aren't official responses, so that's why i'd be great to get them documented), and this is again not an issue of where I'm looking how to fix something - but rather clarifications (ideally even citations) being added as to why these sorts of suggestions pass or not, and why, either way.

[mraccess77]

I find two challenges

• Getting an on-screen keyboard to come up when there is not an input - it's generally not something you can just summon.
• On-screen keyboards that have the appropriate keys like up and down arrows are hard to find.
  The example with the keyboard is really meant when their is an input field that provides the same function.

[scottaohara]

mac and windows do have on screen keyboard apps, which is why this keeps getting brought up as "well why not those?"

but yes, one of the issues i think is often overlooked is that the on screen keyboard for a touch devices is not necessarily gong to have all the keys of a desktop device (tab / arrow keys) - but again this is me assuming some of the rational here, which i'd rather was in the doc than me having to remind/argue/debate with people about, instead.

[patrickhlauke]

mac and windows do have on screen keyboard apps, which is why this keeps getting brought up as "well why not those?"

if the site/thing being assessed is only available on those platforms, then I could see an argument that in that case, the OS itself does provide the alternative to the dragging movement. so i can almost see that being used as an argument of why this would be ok (i seem to recall there were similar discussion threads about the ability, on iOS for instance, to define swipe type gestures that can be activated with a single tap using the OS's built-in accessibility features).

for general web content though, you would then still need to offer something for platforms where it's NOT possible to raise the OSK at will, like on iOS/Android for instance (where, to my knowledge, the OSK only appears contextually when in an actual text input), and indeed address the concern that OSKs on those platforms also don't include all keys.