-
Notifications
You must be signed in to change notification settings - Fork 252
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarification needed: dragging movements and on screen keyboards #3858
Comments
I find two challenges
|
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. |
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. |
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.
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.
The text was updated successfully, but these errors were encountered: