Re: Proposed mobile techniques for SC 3.1

GV:  Comments below - marked GV: 


gregg

----------------------------------
Gregg Vanderheiden
gregg@raisingthefloor.org




> On Apr 14, 2015, at 3:56 AM, Michael Pluke <Mike.Pluke@castle-consult.com> wrote:
> 
> Many great points Gregg. 
>  
> I think that one of the points that you raise might be solved if the second bullet was reworded as something like:
> -          Ensuring touch access control for all functionality that is not already operable by physical controls on the device.
> 

GV:   Hmm.  if advisory that is ok.  
This language wouldn’t  cover audio-only communicators (like emergency call buttons or future communication buttons like the badges on star trek.     Keyboard interface access is still possible for those via bluetooth or equiv (which the device will probably already have in order to to work) but touch access is restricted to just a single touch sensor

We don’t have star-trek communicator badges,  but we do have emergency call buttons that could use touch and voice to control them.   

What is the concern about providing touch access to everything non-physical.   We already say they can’t use voice alone for any functionality.   Would that not get you to the same place?       (I thought I thought of an example but can’t remember now.  can you think of one?)

> Maybe the second part of this could be written as an exception to the original simple requirement – but a single sentence may be the most direct way to express things.

GV:  Can you give me an example of what you mean? 


>  
> I think that your offer of some words to clarify the need for keyboard control on all touchscreen devices would be very useful. In my limited experience I have found that people unfamiliar with WCAG 2.0 always interpret keyboard control in the context of:
> -          either a keyboard on the device;
> 
> -          or situations where a conventional keyboard can be attached to the device;
> 
> -          and almost never in terms of other assistive technologies capable of generating keystroke input.
> 

GV:  I think you are spot on with this observation. 

> I’ve even seen hints of this confusion in some WCAG discussion threads!
>  
> The WCAG 2.0 term “keyboard interface” can also mislead engineers who may have come from a hardware background as they tend to immediately think in terms of things like Bluetooth, RF, PS/2, etc.. 

GV:  ah - they think of the hardware interfaces but not the software ones.      Good thought 
( The Bluetooth interface though is the primary one for touchscreen only devices to provide physical keyboard and alternate keyboard access.  )

>  
> Some helpful explanatory words might ensure that nobody can misinterpret the intent of this important requirement.
































































































>  
> Best regards
>  
> Mike
>   <>
> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
> Sent: 14 April 2015 05:48
> To: Kun Zhang
> Cc: Andrew Kirkpatrick; GLWAI Guidelines WG org
> Subject: Re: Proposed mobile techniques for SC 3.1
>  
> comments below
> 
> gregg
>  
> ----------------------------------
> Gregg Vanderheiden
> gregg@raisingthefloor.org <mailto:gregg@raisingthefloor.org>
>  
>  
> 
>  
> On Apr 13, 2015, at 9:25 AM, Kun Zhang <kunzhang@w3.org <mailto:kunzhang@w3.org>> wrote:
>  
> If "Keyboard" control is very important for Touchscreen Devices, it should have a clear definition, imagine touchscreen device is ATM, watch, GPS, this is not always make sense in general keyboard definition. 
> 
> - Kenny Zhang
> 
> 在 2015/4/10 0:51, Andrew Kirkpatrick 写道:
> 3.1 Keyboard Control for Touchscreen Devices
> ·         Ensuring keyboard control for all functionality
> Ensuring touch access control for all functionality 
> ·         Ensuring that users are not trapped in content (using touch and keyboard) 
> ·         Defining the hover, focus, selected and touch (regular, long) states 
> Use focus, hover and select states consistently and in a way that follows the respective platform conventions 
> Questions:
> 1)      Does each technique make sense to you?  (for now these are just titles, so it can be a challenge to be certain)
>  
> GV: <start>
>  
> Ensuring keyboard control for all functionality
> YES - with WCAG exceptions of course. 
>  
>  
>  
> Ensuring touch access control for all functionality
> Hmmmm.   I think this is hard.  For example — where you have physical toggle keys (e.g. the sound/off switch on the side of the device) how would you toggle that physical control from the screen. And if you did - then the switch on the side would show the wrong status. 
> Home button is another one.. but that COULD be made available.
>  
> I think that as an advisory it is fine. 
>  
> Ensuring that users are not trapped in content (using touch and keyboard)
> For keyboards this is handled under a  different SC
> For touchscreens I don’t think I would list this (here nor under the “TRAP” SC) unless you can think of some way that you CAN trap someone with a touchscreen. 
>  
> Defining the hover, focus, selected and touch (regular, long) states
> Use focus, hover and select states consistently and in a way that follows the respective platform conventions
>  
> Not sure I understand this one - what does it mean?   I presumed they are defined if code is written implementing them.   Do you mean explain?
>  
> GV: <end>
> 
> 
> 2)      Do you agree that the referenced success criteria is applicable to each suggested technique, or that the technique is applicable to the SC)?
> GV: I don’t think 3.1 applies to touchscreen.   But as advisory I think you could attach touchscreen items here. 
> 
> 
> 3)      Do you think that there is another technique that this might better be an example for instead of a technique on its own?
> GV: Hmmm.  Interesting thought.   Nothing comes to mind.    
>  
>             • Ensuring keyboard control for all functionality
> This one of course IS SC 2.1.1
>  
>             • Ensuring touch access control for all functionality
> This would not be an example of any technique I know of.
>  
>             • Ensuring that users are not trapped in content (using touch and keyboard)
> For touch I don’t think it makes sense.  At least I have never heard of or seen it.
> For keyboard it is already SC 2.1.2 
>  
>             • Defining the hover, focus, selected and touch (regular, long) states
> again Im not sure I understand what this means exactly. 
>  
>                         • Use focus, hover and select states consistently and in a way that follows the respective platform conventions
> This one should be attached to  SC 3.2.3 Consistent Navigation and 3.2.4 Consistent Identification 
>  
> 4)      Do you think that each is likely to be sufficient or advisory?
> All are advisory.  
>  
> The keyboard aspects of two are SC - so not really techniques. 
> The rest don’t satisfy any SC so they can’t be sufficient.
>  
> 
> 
> 5)      Are there other techniques that you can think of that address the SC in the mobile space?
> No. But a good explanation is needed to people understand the importance of access via keyboard interface on a device that has no physical keyboard. 
>  
> If you don’t have one - I could help put one together from notes around the time this was done — but with special emphasis on Keyboardless devices. 
>  
>  
> Gregg
>  
>  
> 
> 
>  
>  
> Thanks,
> AWK
>  
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe Systems 
>  
> akirkpat@adobe.com <mailto:akirkpatrick@adobe.com>
> http://twitter.com/awkawk <http://twitter.com/awkawk>
> http://blogs.adobe.com/accessibility <http://blogs.adobe.com/accessibility>