- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Thu, 21 Jul 2016 09:58:15 +0100
- To: GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
On 21/07/2016 04:51, Gregg Vanderheiden RTF wrote: > Patrick since iOS 8 - you can install alternate keyboards that use > anything you want as input, instead of the build in keyboards. So > sip-and-puff keyboard, voice input keyboard, and scanning input > keyboards etc plug into iOS do create keystrokes and work with any > program that is set up to take keyboard input from the iOS keyboard. > These 3rd party keyboards work with ALL programs on iOS just like the > built in keyboard (unless a program can detect a third party keyboard > and block its use. I don’t think they can and have never heard of it — > but it may be possible). > > I think Android has supported this even longer. This is not about alternate keyboards. The point that I and Jonathan were making is: on iOS/Android there is no way to raise / make the on-screen keyboard appear arbitrarily. It is only shown when focus is set to a form control or similar that allows for text/numerical entry. (The situation is different on full-fledged OSs like Windows 10 on a touch-enabled tablet/laptop, where you have a switch in the taskbar to show the on-screen keyboard at any point) So, as a rough example: say you created a webpage that has a keydown/keyup listener just on the <body> element, and your JS reacts to various keystrokes to activate functionality. This works fine (and passes 2.1.1) in situations where a user always has access to a keyboard/keyboard-like interface, but will fail on iOS/Android because the on-screen keyboard will simply not be shown to the user, the user can't toggle/show the keyboard when they want, and thus cannot activate those keys to then send the keystrokes that then trigger the functionality. In any case, I think this discussion is tangential to the larger discussion thread here. Just wanted to clarify that point. P >> On Jul 20, 2016, at 1:56 PM, Patrick H. Lauke <redux@splintered.co.uk >> <mailto:redux@splintered.co.uk>> wrote: >> >> scanning, sip and puff, voice input don't act like actual >> keyboards...they do not send keystrokes. >> >> they can be used in concert with an on-screen keyboard, but on ios and >> android it is not generally possible to bring up the on-screen >> keyboard arbitrarily - it only appears when the user is on an element >> that allows key entry... >> >> (not to reiterate the lenghty thread from the mobile TF list) >> >> -- >> Patrick H. Lauke >> >> >> On 20 Jul 2016, at 16:58, Gregg Vanderheiden >> <gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>> wrote: >> >>> Please — the requirement is NOT that things work with a physical >>> keyboard. Only the keyboard interface. This can be any keyboard >>> installed on the phone itself — including scanning or sip and puff or >>> voice input or…. (it CAN also be external— but only if that is >>> what a person wants to use) >>> >>> /gregg/ >>> >>>> On Jul 18, 2016, at 10:44 AM, Jonathan Avila >>>> <jon.avila@ssbbartgroup.com <mailto:jon.avila@ssbbartgroup.com>> wrote: >>>> >>>> Ø I don't see how I can ever fail someone on 1.4.2 anymore, thanks >>>> to James pointing this out. If we are looking to not cause SC bloat >>>> with the new SCs, perhaps we can make a new category for SCs which >>>> have been largely overcome by advances in User Agents etc... which >>>> still apply to 2.1 but are folded away somewhere so 2.1 is not >>>> bloated with SCs that developers don't need to worry about. >>>> >>>> I respectfully disagree with you David. Carrying around a physical >>>> keyboard with my iPhone so I can press control+M to mute audio is >>>> not acceptable. >>>> >>>> Jonathan >>>> > -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Thursday, 21 July 2016 08:58:39 UTC