W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2015

Re: Proposed mobile techniques for SC 3.1

From: Gregg Vanderheiden <gregg@raisingthefloor.org>
Date: Mon, 13 Apr 2015 23:48:13 -0500
Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
Message-Id: <B336E4B1-738B-480D-A3AC-0191FE554E23@raisingthefloor.org>
To: Kun Zhang <kunzhang@w3.org>
comments below

gregg

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




> On Apr 13, 2015, at 9:25 AM, Kun Zhang <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>
>>  
> 
Received on Tuesday, 14 April 2015 04:48:45 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:19 UTC