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

My desire is not  for us to spill a lot of ink and time over a vetting
process but rather to see where we'd all be reasonably agreeable to drop
some of the less mature ones that will require a ton of work and will
likely get lots of push back at the group level and from outside
stakeholders. The earlier we weed, the better, I'd say.


- Issue 61 Pointer Gestures
https://github.com/w3c/wcag21/issues/61

Ok, let's leave it for the larger group. I wrote a blog early this year
asking users if WCAG.NEXT should require everything to work with mouse
(Pointer)
http://www.davidmacd.com/blog/should-WCAG-require-all-functionality-by-mouse.html

I got no feedback to include the mouse requirement in WCAG next and assumed
not many people feel strongly about it. But maybe there are other reasons
no one said "yes, let's do this".

Regarding
Issue 62 Keyboard with AT (that remaps key input)
https://github.com/w3c/wcag21/issues/62

SC 2.1.1 requires content to work with keyboard. Conformance Requirement 4
requires that only accessibility supported ways of using technologies are
used. So, if keyboard accessibility breaks when a Screen Reader (that is
relied upon for conformance) is running, then the content fails Conformance
Requirement 4. I feel this reasonably covers this use case at a WCAG 2.1
level. What is not covered currently, that this covers?

- Issue 72 Non- Interference of AT
Sounds like there is reasonable unity in closing it.

- Issue 64 Concurrent Input Mechanisms
https://github.com/w3c/wcag21/issues/64

Sounds like fairly good unity in closing it.



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, Dec 9, 2016 at 6:16 AM, Patrick H. Lauke <redux@splintered.co.uk>
wrote:

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