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

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