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