What sound, if any, should be produced on alt-input attempts to go past min & max values on a slider

[jbphet]

Issue https://github.com/phetsims/greenhouse-effect/issues/131 is about what sound should be produced by a number picker if the user attempts to go beyond the min or max values when using keyboard navigation. We just had a design meeting to discuss this, and realized that it is a general question that pertains to sliders too. As of this writing, sliders make no sound if users try to move beyond the min/max values using keyboard nav, but number pickers repeat the min/max sounds in this scenario. We decided in this meeting to make number pickers consistent with slider and produce no sound in this case, but requested that @terracoda do a little research to be sure that this is the behavior we want. In the meeting we noted that this is similar to, but not exactly the same, as the case where the user tries to interact with a disabled UI component.

Assigning to @terracoda for follow-up.

[zepumph]

I have an opinion!

In the a11y team, we seem to be moving towards an approach where feedback responds to input, as opposed to model changes. This philosophy has created great user experience (in my opinion) for voicing and description where we can guide users with feedback even if (and especially if) an interaction did not produce model changes. From this, in Ratio and Proportion we added a "go beyond boundary" sound that serves as a error case of sorts to demonstrate that you tried to move in the direction of the edge you are already at. We accompany this with a hint like "move the other direction to experience other stuff." The sound is very pleasant to me, and great design (good job the not-me's of that RAP team who came up with it).

but requested that @terracoda do a little research to be sure that this is the behavior we want.

Seems reasonable, but also, what does this really entail. Is TS going to go out and find all the examples of custom sliders on the internet? I'm not really sure where I'd start, nor do I feel like precedent is that helpful in this case. To me it is more of a question of what assistance can we give our users. If someone continues to do the wrong thing, shouldn't we give more feedback as opposed to less?

I also don't think it would be too hard to add this sound into NumberPicker and slider-like components.

Let me know if I can help at all!

[terracoda]

Well said, @zepumph. Thanks for your comment.

[terracoda]

Objects that slide around and hit visual boundaries typical have an edge sound and often have bespoke descriptions that try to indicate to a learner that they have hit the edge, e.g., "Last stop, left" and "Last stop, right" in GFLB. In some cases current state information is also provided, so learners know the state is not changing as they try to go beyond the limits placed on the interactive object.

Regarding number spinners, they tend to be less nuanced as they tend to make discrete and precise changes. We have 2 sonified number picker designs - one in GFLB and one in RaP.

In GFLB, I think the tone changes with each mass value change. It is hard to tell as there is also a corresponding pitch sound for the change in force that happens simultaneously. There seems to be no special sound when the mass is increased to 10 or decreased to 1. And there is no sound - just silence if a learner tries to go beyond 1 or 10. In the descriptions, the learner is provided with a description of the current state of the mass sphere. This descriptions provides a comparative description of the sizes (or densities) of the 2 spheres and the current size and value of the force arrows. This strikes a nice balance and I don't think a sound to accompany that state description would be beneficial.

For RaP's number spinners, there are no tonal changes on the intermediate numbers, but there is a tonal change on the min/max numbers. I think this design works well for this number spinner which is more conceptual. The pitch changes and the min/max values help to indicate the edge, so again here, I think there is no need for a sound to indicate going beyond. The learner will stop getting feedback and should be able to deduce that they've hit the min or max.

In retrospect, I think by default, it's likely best not to sonify attempts to go beyond an edge. We have found that sonifying reaching an edge is indeed important and how to communicate that edge depends heavily on the situation. This is relevant to both number pickers and sliders.

If there is going to be a default non-pedagogically relevant sound for sliders and number spinners, it might be a good idea to have the min and max sounds have an option to be different from the in between values - as we did on the number spinners in RaP.

I am re-assigning to @jbphet for comment.

[jbphet]

In the comment just above, towards the end, @terracoda says "I think by default, it's likely best not to sonify attempts to go beyond an edge." This is in agreement with what the sound designers have said, so I think we will go with this, at least for the time being.

@terracoda also said, "[I]t might be a good idea to have the min and max sounds have an option to be different from the in between values..." There is already such an option, and it is used in the default case for sliders as well as most if not all of the sliders that have been recently sonified using the recently-added common-code sound capabilities.

So, I think we've reached a decision, and this can be closed.