[I'm one of the "accessibility experts" that Alan wanted to run this by...]
Use of the shift key has been the standard for a long time across all desktop environments; why Mac OS is now reportedly using the <Return> key now is something I can't speak to at this time.
Given the nature of the disabilities that need SlowKeys, requiring that there be no mouse movement for the entire 8 seconds that Shift is held down seems fine - I don't believe this will negatively impact anyone who needs SlowKeys.
Shifting (pardon the pun) to having desktop environments explicitly turn this on and explicitly provide UI for it (e.g. when held down pop up a confirmation dialog box) also seems like a fine change. I would only be concerned about getting the timing & coordination right for that, so that we don't harm users who need this during a transition to a new model for the roles that the various components are playing.
I think it would be a mistake to require a longer duration of holding down the key. I think it would be a mistake to move to a different key - particularly something that may not be on all keyboards.
I am concerned about emitting a tone at 4 seconds with activation at 8 seconds, for the simple reason that users might erroneously think 4 seconds was enough to activate. But as there are (far) fewer users who need this compared to the general population, this would be a relatively easier education task. BUT... shifting this to the desktop environment's responsibility for UI notification is probably the better way to go; a beep is more easily missed (in both directions) than a dialog box appearing that explains what is going on.
[I'm one of the "accessibility experts" that Alan wanted to run this by...]
Use of the shift key has been the standard for a long time across all desktop environments; why Mac OS is now reportedly using the <Return> key now is something I can't speak to at this time.
Given the nature of the disabilities that need SlowKeys, requiring that there be no mouse movement for the entire 8 seconds that Shift is held down seems fine - I don't believe this will negatively impact anyone who needs SlowKeys.
Shifting (pardon the pun) to having desktop environments explicitly turn this on and explicitly provide UI for it (e.g. when held down pop up a confirmation dialog box) also seems like a fine change. I would only be concerned about getting the timing & coordination right for that, so that we don't harm users who need this during a transition to a new model for the roles that the various components are playing.
I think it would be a mistake to require a longer duration of holding down the key. I think it would be a mistake to move to a different key - particularly something that may not be on all keyboards.
I am concerned about emitting a tone at 4 seconds with activation at 8 seconds, for the simple reason that users might erroneously think 4 seconds was enough to activate. But as there are (far) fewer users who need this compared to the general population, this would be a relatively easier education task. BUT... shifting this to the desktop environment's responsibility for UI notification is probably the better way to go; a beep is more easily missed (in both directions) than a dialog box appearing that explains what is going on.