Re: Proposal: expanding/modifying Guideline 2.1 and its SCs (2.1.1, 2.1.2, 2.1.3) to cover Touch+AT

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



*Can**Adapt* *Solutions Inc.*
Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

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