Re: Proposed new Customizationof shortcut SCs to reduce risk of accidental voice activation

I don't think the on/off option is a good idea – I wouldn't want to give 
developers an easy way to simply leave a group of users out. I agree 
that if allowing the user to customize with a control key is more 
straightforward than a character sequence, it makes sense to separate 
those at different levels.

Cheers,
Kim

On 7/21/2016 5:07 PM, David MacDonald wrote:
> Agree
>
> Cheers,
> David MacDonald
>
> *Can**Adapt**Solutions Inc.*
>
> Tel:  613.235.4902
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd <http://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 Thu, Jul 21, 2016 at 3:23 PM, Patrick H. Lauke 
> <redux@splintered.co.uk <mailto:redux@splintered.co.uk>> wrote:
>
>     On 21/07/2016 18:57, David MacDonald wrote:
>
>         ​​I've moved my proposals to the bottom of your page so it's
>         all together.
>
>         I think it will be a stretch to force devs to make every hard
>         coded
>         shortcut a customizable shortcut that accepts a string. But
>         I'm fine
>         with trying to push it through if its technically possible. It
>         appears
>         Jonathan is saying its quite complicated.
>
>         We should however, have a fallback position that helps solve
>         the problem
>         of colliding keys and VR systems, if the original proposal is
>         rejected.
>
>
>     I agree with Jonathan here that listening for a character
>     *sequence*, as opposed to a single character, requires more work
>     on the part of the developer (essentially, the script needs to
>     listen and store any keystrokes that happen sequentially before a
>     certain cut-off/timing - so, for instance, keystrokes that are
>     less than 1 sec apart - and only at the end - when no more
>     keystrokes have been received for 1 sec - look over the entire
>     sequence that was captured).
>
>     I think we can tentatively draft something up, but I would
>     definitely go for a "a mechanism is available" language, since it
>     may well be down to AT/UAs to handle this (for instance, it could
>     be reasonable for AT to switch into different internal modes
>     depending on whether the current focus is on an editable/text
>     entry field or not...if it's not, it could for instance only
>     interpret very clear specific single characters being spoken, with
>     pauses, to send actual keystrokes, so that if the user says an
>     entire word, it doesn't trigger all those separate keys).
>
>     Also, as said in IRC/the call, this really feels like a AA for the
>     on/off and a AAA for the customisation.
>
>     P
>     -- 
>     Patrick H. Lauke
>
>     www.splintered.co.uk <http://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
>
>
>

-- 
___________________________________________________

Kimberly Patch
President
Redstart Systems
(617) 325-3966
kim@redstartsystems.com <mailto:kim@redstartsystems.com>

www.redstartsystems.com <http://www.redstartsystems.com>
- making speech fly

Blog: Patch on Speech
+Kim Patch
@RedstartSystems
www.linkedin.com/in/kimpatch <http://www.linkedin.com/in/kimpatch>
___________________________________________________