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

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 | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Received on Thursday, 21 July 2016 19:24:01 UTC