Re: Perhaps we can follow the LVTF and close a few of our proposals

oops what about 71?

- Issue 71 Non- Interference of AT
https://github.com/w3c/wcag21/issues/7
<https://github.com/w3c/wcag21/issues/72>1

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 Sat, Dec 10, 2016 at 7:09 AM, David MacDonald <david100@sympatico.ca>
wrote:

> Sounds like there is not consensus on closing:
> - 61 Pointer Gestures,  62 Keyboard with AT, 64 Concurrent Input
> Mechanisms
>
> So we'll leave them open, and let the larger group deal with them.
>
> What about 72?
>
>
> 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 Sat, Dec 10, 2016 at 5:28 AM, Detlev Fischer <
> detlev.fischer@testkreis.de> wrote:
>
>> I support Patrick's assessment that we should retain issue 61 "Pointer
>> gestures" and 62 "Keyboard with AT" *if* SC 2.1.1 cannot be extended.
>>
>> Best, Detlev
>>
>> Sent from phone
>>
>> > Am 09.12.2016 um 12:16 schrieb Patrick H. Lauke <redux@splintered.co.uk
>> >:
>> >
>> >> On 09/12/2016 02:22, David MacDonald wrote:
>> >>
>> >> The LVTF has reviewed their submitted issues and closed 5 of them. So
>> >> they have gone from 14 to 9 submitted SCs to the larger WG. Perhaps we
>> >> can take a similar initiative to close several of our 14. Any work we
>> >> can do at the TF level to tighten up our list, will help the Working
>> >> Group, given that there are currently 63 Proposed SCs and many will
>> have
>> >> to be dropped. I would like to propose we close some of the less mature
>> >> ones unless some of us feel strongly that they:
>> >>
>> >> - Can be cleaned up to meet the acceptance requirements of a Success
>> >> Criteria https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteri
>> >> <https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Success_Criteri>
>> >> - Will help significant numbers of people with disabilities overcome a
>> >> known barrier
>> >> - Can be tested reasonably easily
>> >> - Can be accomplished clearly and easily by devs
>> >>
>> >> I've closed out Issue #3 which was M16
>> >>
>> >> I propose we close the following:
>> >>
>> >> - Issue 61 Pointer Gestures
>> >> https://github.com/w3c/wcag21/issues/61
>> >> <https://github.com/w3c/wcag21/issues/61>
>> >
>> > Strongly feel that no, we shouldn't close this. If a
>> website/application is built to require gestures/swipes/pinches etc, it
>> WILL generally not be usable for a range of users - e.g. users who lack
>> precise enough fine/gross motor control, users who use alternative
>> mouse-type devices which may not easily allow for particular
>> gestures/movements, touchscreen users with touch-AT running (unless they
>> laboriously go through some form of gesture passthrough), etc.
>> >
>> >> - Issue 62 Keyboard with AT (that remaps key input)
>> >> https://github.com/w3c/wcag21/issues/62
>> >> <https://github.com/w3c/wcag21/issues/62>
>> >
>> > You comment that this could be rolled into another SC / is already
>> mostly covered by 2.1.1. On the latter, I disagree...current wording of
>> 2.1.1 does not cover situations where keyboard may already be intercepted
>> by AT. As for rolling it into another SC, one of the original reasons why
>> we (well, I) decided to split this out into a new SC was exactly because we
>> were told that existing SCs can't be touched/modified.
>> >
>> > I'd say submit as is, with note to WG that this may be a candidate for
>> expanding 2.1.1 if the WG decides it's kosher at last to do it.
>> >
>> > This does affect users with disabilities using AT disproportionately
>> more than non AT users, and it is a problem I've encountered quite
>> regularly in my audits last year (it's sort of the flip-side of sites that
>> indiscriminately add role="application" as noted in the proposed Issue 72
>> Non-interference one - if we are dropping that one, see below, then it
>> would be good to also note that problem here as a "but don't overdo it..."
>> counter-example).
>> >
>> >> - Issue 64 Concurrent Input Mechanisms
>> >> https://github.com/w3c/wcag21/issues/64
>> >> <https://github.com/w3c/wcag21/issues/64>
>> >
>> > I'm fairly neutral on this one. It IS a problem (and one I've been
>> trying to fight in various guises, such as in my presentations where I try
>> to drum it into developers to stop thinking about touch OR mouse OR
>> keyboard and to instead think about touch AND mouse AND keyboard), but I
>> can see the argument that it's not one that burdens users with disabilities
>> significantly more than all other users, so mostly a problem of
>> usability/UX.
>> >
>> >> - Issue 72 Non- Interference of AT
>> >> https://github.com/w3c/wcag21/issues/72
>> >> <https://github.com/w3c/wcag21/issues/72>
>> >
>> > I'd be mildly in favour of dropping this one.
>> >
>> >> To my mind most of these are mostly covered in the standard, do not
>> >> promise to make huge differences in the lives of people with
>> >> disabilities,
>> >
>> > Would love to know your rationale for each of the ones you propose
>> dropping.
>> >
>> >> and would require bandwidth we don't have to bring up to
>> >> the level of the others. This will save us, and the group about 100
>> >> hours, literally, and would leave us with 10 tight mature SC
>> submissions
>> >> and will help set an example for COGA to follow LVTF and MATF in
>> closing
>> >> some issues.
>> >
>> > P
>> > --
>> > Patrick H. Lauke
>> >
>> > www.splintered.co.uk | https://github.com/patrickhlauke
>> > http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> > twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>
>>
>>
>