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

I get it....

"Let's think AND not OR..."

Its a great idea. But this is a 2.1. There are incredible problems to
overcome with this.

   1. It will be very difficult to test. The ramifications are without
   bounds.
   2. The wording does not meet the SC requirements and I don't know how to
   fix that in a 2.1 SC model

But again I'm not looking for a big discussion here if the intent is to
make the group decide ... it's just take a lot of band width of very busy
people over there... and I'm not going to invest further in it, because I
don't think it has a future in 2.1. I think the broader web community will
fix this.

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 8:12 AM, Kim Patch <kim@redstartsystems.com> wrote:

> I strongly support keeping this one. This is also a problem I've been
> trying to fight in various guises as well, some firmly in the accessibility
> area.
>
> There's been a long history of focus issues with folks using a combination
> of speech and keyboard. And Google doc menus are not compatible with
> mouseless browsing tools because the keystrokes used by those tools are
> conscripted by Docs.
>
> I think it's going to be increasingly important going forward for
> developers to think more about the use of multiple input methods that
> aren't aware of each other. The combination of speech and pointer is a
> particularly powerful and enabling one for folks with mobility issues.
>
> Encouraging developers to think AND instead of OR also makes the
> importance of user customization more obvious in areas where the needs of
> the different input methods might clash (e.g. single key shortcuts work
> well for keyboard users but spell disaster for speech users).
>
> Cheers,
> Kim
>
> On 12/9/2016 6:16 AM, Patrick H. Lauke wrote:
>
> On 09/12/2016 02:22, David MacDonald wrote:
>
>
> - Issue 64 Concurrent Input Mechanisms
> https://github.com/w3c/wcag21/issues/64
> <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.
>
>
> --
> ___________________________________________________
>
> Kimberly Patch
> President
> Redstart Systems
> (617) 325-3966
> kim@redstartsystems.com
>
> www.redstartsystems.com
> - making speech fly
>
> Blog: Patch on Speech
> +Kim Patch
> @RedstartSystems
> www.linkedin.com/in/kimpatch
> ___________________________________________________
>