Reset Alert over-ridden by slider alerts

[terracoda]

In #74, @terracoda said:

The reset alert is gets over-ridden by the slider alerts. This happens after sliders have changed, and then the reset button is pressed.

Alert for Reset:

• Is not over-writing or replacing the slider alerts on reset after interaction changes a value of the slider. Reset works just fine if no interaction has taken place.
• In A11y View the reset alert is quickly replaced with the slider alert if there has been a change to the slider positions.
• The reset alert should replace/over-ride the slider alert on reset.
• The same issue occurs in the visual a11y version. Using Voice Over, the reset alert is interrupted by the slider alert that follows it.

[jessegreenberg]

Thanks @terracoda. ResetAllButton needs to use scenery-phet/UtteranceQueue now that it is replacing scenery-phet/AriaHerald. That should solve the problem of overriding alerts.

[jessegreenberg]

@zepumph would you have time to work on this?

[zepumph]

Yeah!

[zepumph]

@jessegreenberg please review. I was not sure what the UtteranceQueue equilelent of AriaHerald.enabled was, so to enable it again I am clearing the queue, and then unmuting it to "start over" after a reset. What do you think?

[jessegreenberg]

I agree that seems like the best way to do it with the current API.

Would it be useful to have a way to disable the UtteranceQueue like we could with AriaHerald?

If disabled, we no-op in addToFront, addToBack and next?

[zepumph]

That would save us a step and be a bit more explicit. Current api:

• "disable" === mute the queue
• "enable" === clear the queue and unmute
• Limitation:
  1. Let's say you have Utterance queue currently populated with utterances 1, 2, and 3.
  2. Then you want to disable the queue while utterances 4 and 5 were going to be added.
  3. Now you want to play utterances 1, 2, 3. Currently there is not way because "muting" is still passing items through, and "clearing" is removing previous queue items as well.

I'm not sure what the use case is, or if there is one, but it backs up the idea that we should have a "disable" "enable" feature set for Utterance Queue as well.

[jessegreenberg]

Then it seems like it might also be useful to pause the queue? Apart from disable and enable, to support that case we might want to

• pause queue
• prevent new Utterances from being added
• Resume queue

[zepumph]

Maybe when the UtteranceQueue is paused, things can still be added, but when disabled it's a no-op

[jessegreenberg]

Yes, that sounds like a good way to categorize it.

[zepumph]

I added enabled disabled, and I think it works really well for the reset alert in this issue. @jessegreenberg please review. Should we implement pause as well?

[jessegreenberg]

Looks great @zepumph, but I am wondering why you chose to no-op clear when the queue is disabled? If the queue is disabled we might still want to quickly remove all utterances?

[jessegreenberg]

But I verified that ResetAllButton alerts are working correctly!

[zepumph]

I agree. clear is no longer a noop (spoken like 'nuup'). Closing