Re: Should we drop any WCAG 2 SCs in 2.1?

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