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

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

Received on Saturday, 10 December 2016 10:29:06 UTC