- From: Detlev Fischer <detlev.fischer@testkreis.de>
- Date: Fri, 8 Jul 2016 16:26:47 +0200 (CEST)
- Cc: public-mobile-a11y-tf@w3.org
I fully get the advantage of changing 2.1 SCs by phrasing the requirements on a more generic level. However, one concern is that the new wording (whether non-pointer or keyboard equivalent) will make the SC harder to understand for non-techies. Separating keyboard and other (non-pointer / keyboard equivalent) would make sense in scenarios where the focus is clearly just keyboard - i.e. for clients wanting to test desktop-focused apps that are not meant (or never likely to be) used on touch devices and may offer custom keyboard shortcuts, so that they explictily exclude touch (and any new touch specific SCs) in their a11y support baseline. For these clients, retaining a separate, unchanged SC 2.1 keyboard would have advantages. (Alternatively there may be touch only systems - think of info kiosk, LCD Panel to control devices - where you just test for touch accessiblity and disregard keyboard.) In terms of testing, different SCs (by input method) would call for different actions - using the external keyboard, and using touch (testing swipe / double tap). The final point is granularity. Keeping SCs separate, I can immediately see the respective result per input mode - for example, I might see "this app fully works with KB (one SC) but fails to work with touch/AT (another SC)". The granularity of umbrella SCs like 1.3.1 is a major headache since it means you have to delve into massive test results per page/SC to spot whether the problem was headings, data tables, lists, inline markup, semantic labels, or whatever. That's why many WCAG-based test procedures felt the need to split the SC into several checkpoints. We need to take the comprehensibility and usability of the SCs into account when considering the modification of SCs under Guideline 2.1. Detlev -- Detlev Fischer testkreis c/o feld.wald.wiese Thedestr. 2, 22767 Hamburg Mobil +49 (0)157 57 57 57 45 Fax +49 (0)40 439 10 68-5 http://www.testkreis.de Beratung, Tests und Schulungen für barrierefreie Websites David MacDonald schrieb am 08.07.2016 15:22: > > On the Mobile call I said, in principle I'm fine with widening the requirements for 2.1.1 but would I not be ok if any of the requirements of 2.1.1 in any way (explicitly or implicitly) ended up with fewer requirements for keyboard. (a least not without a lot of study which is outside the scope of a 2.x) > > > I think everybody is on the same page with that and Patrick has assured us that that is not the aim, but rather to widen and make a more useful higher level requirement which can apply to more types of technology. > > > The challenge is ensuring the wording continues to require that on mobile platforms such as iOs or Android all functionality needs to work with a keyboard, and that things that would currently fail WCAG 2 for keyboard would also fail 2.1. My reading of early drafts seemed to read like an OR statement, even if they may not have actually said that. > > > I've learned from seeing people misinterpret WCAG 2 (such as zoom requirements) in the trenches that the interpretation by the public of the standard can become sort of defacto normative... > > > Cheers, > David MacDonald > > > CanAdapt Solutions Inc. > Tel: 613.235.4902 > LinkedIn <http://www.linkedin.com/in/davidmacdonald100> > > > twitter.com/davidmacd <http://twitter.com/davidmacd> > > GitHub <https://github.com/DavidMacDonald> > > www.Can-Adapt.com <http://www.can-adapt.com/> > > > > Adapting the web to all users > > Including those with disabilities > > > If you are not the intended recipient, please review our privacy policy <http://www.davidmacd.com/disclaimer.html> > > > On Fri, Jul 8, 2016 at 6:27 AM, Alastair Campbell <acampbell@nomensa.com <mailto:acampbell@nomensa.com> > wrote: >> > Note that I'm chair of that group, as well as a co-editor of the spec... ;) >> >> Ah, oops! I had a vague feeling you were involved but didn’t see your name on it, so to speak. >> >> Anyway, it supports the point that the W3C specs should align, and WCAG needs to catch up on this one. >> >> >> > My one concern with calling touch+AT "keyboard-equivalent" is that this >> > scenario does not fire any actual "faked" keypresses, so technically not >> > quite accurate. Then again, maybe this can be addressed in the glossary >> > definition and handwaved/papered over, as it's really the end result >> > (that it moves the accessibility focus/caret around) that matters here. >> >> Personally I think equating it to keyboard equivalent and focusing on the higher level robust events makes sense and is the easy method to communicate. It would fit into the training I give fairly easily, for example. But open to other suggestions. >> >> Cheers, >> >> -Alastair >> >
Received on Friday, 8 July 2016 14:27:14 UTC