Comment 1 by jteh on 2013-10-22 01:16
This one is unfortunately rather subjective. We don't interrupt speech for the volume keys, since adjusting the volume will affect the volume of speech output and the user may wish to hear this as it is happening. I'd argue the other multimedia keys aren't any different to other command keys (function keys, etc.); they all perform some command. If we don't interrupt speech, they can't be reported as command keys using speak command keys, which as you say might be a problem for new users.

From an implementation point of view, it's fairly easy to do either; it's just a matter of what the KeyboardInputGesture.speechEffectWhenExecuted property returns.

@jcsteh Could you please clarify exactly which keys are being referred to as multimedia keys in the context of this ticket? Play/Pause is one that comes to mind, but it would be beneficial if you could specify all multimedia keys that this ticket encompasses, since we have no means of contacting the original author of this ticket.

The reporter wasn't specific, but I assumed play/pause, next track, previous track, etc. Volume up/down was also covered, but we don't interrupt speech for those already.

I don't think it's unreasonable for play/pause, next, previous, etc. to interrupt speech, just as pressing a function key interrupts speech. In particular, the use case given above seems strange to me (skipping tracks while programming). Everyone is different, but from what I've seen, programming doesn't usually involve reading large amounts of text without any input from the user, so interrupting reading of a line (for example) to change tracks doesn't seem unreasonable.

Closing as won't fix. If a compelling use case can be given (and an argument for why these shouldn't be treated like function keys, etc.), we can reconsider.