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

Re: Proposed mobile techniques for SC 3.1

From: Alan <alands289@gmail.com>
Date: Fri, 17 Apr 2015 07:41:05 -0400
Message-Id: <53884636-44B0-4FCD-A278-1AC669C5ABF4@gmail.com>
Cc: Jonathan Avila <jon.avila@ssbbartgroup.com>, Gregg Vanderheiden <gregg@raisingthefloor.org>, Kun Zhang <kunzhang@w3.org>, Andrew Kirkpatrick <akirkpat@adobe.com>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
To: Michael Pluke <Mike.Pluke@castle-consult.com>
I like this wording. 

Sent from my iPhone

> On Apr 17, 2015, at 5:46 AM, Michael Pluke <Mike.Pluke@castle-consult.com> wrote:
> 
> Perhaps some text that we wrote in the European equivalent of Section 508 (EN 301 549) in relation to closed functionality might help with the trapping issue. The relevant text is:
>  
> “Where input focus can be moved to a user interface element, it shall be possible to move the input focus away from that element using the same mechanism, in order to avoid trapping the input focus.”
>  
> This is very generic and would apply to moving the focus using touch, voice, or any other means.
>  
> Best regards,
>  
> Mike Pluke
> Castle Consulting Ltd.
> 76 Cowper Street
> Ipswich
> Suffolk
> IP4 5JA
> England
>  
> From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com] 
> Sent: 17 April 2015 03:18
> To: Gregg Vanderheiden; Kun Zhang
> Cc: Andrew Kirkpatrick; GLWAI Guidelines WG org
> Subject: RE: Proposed mobile techniques for SC 3.1
>  
> [Gregg wrote]
> Ø  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. 
> 
> iOS has assistive touch which lets you control the same options that are toggled by the physical phone controls.  For example, with assistive touch you can mute or unmute the phone by touching the assistive touch options and it will actually override the controls on the phone.  That is even though the phone’s toggle is on mute if you turn Assistive Touch’s to unmute it will be unmuted!  So yes, this is very possible is used today.
> Ø  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. 
> 
> When VoiceOver is active you could trap someone.  For example, a native app could be designed to not support explore by touch by not using accessibilityFrame properly but it could still support swiping but trap the user when swiping.  This might be more difficult for web pages – but perhaps you could trick the explore by touch feature by using overlaid content with different z-indexes.
>  
> Jonathan
>  
> -- 
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group 
> jon.avila@ssbbartgroup.com
>  
> 703-637-8957 (o) 
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>  
> From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org] 
> Sent: Tuesday, April 14, 2015 12:48 AM
> 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
>  
>  
> 
>  
> 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
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>  
>  
>  
Received on Friday, 17 April 2015 11:41:34 UTC

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