RE: Proposed mobile techniques for SC 3.1

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<mailto:jon.avila@ssbbartgroup.com>

703-637-8957 (o)
Follow us: Facebook<http://www.facebook.com/#%21/ssbbartgroup> | Twitter<http://twitter.com/#%21/SSBBARTGroup> | LinkedIn<http://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog> | Newsletter<http://eepurl.com/O5DP>

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<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://blogs.adobe.com/accessibility