RE: Proposed mobile techniques for SC 3.1

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.
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.

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.
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..

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