Delete constrainValue from AccessibleValueHandler

[zepumph]

From https://github.com/phetsims/sun/issues/698 and https://github.com/phetsims/sun/issues/350

A subset of https://github.com/phetsims/scenery/issues/1298

@samreid and @jessegreenberg and I have just had a large conversation about how constrainValue is being used in My Solar System over in https://github.com/phetsims/my-solar-system/issues/105, and have come to the conclusion that as it interfaces with the step values, it is really really confusing. We recommend deleting it, and keeping constrainValue specific to mouse/touch in Slider, and the following as the API for AccessibleValueHandler:

• keyboardStep
• shiftKeyboardStep
• pageKeyboardStep
• a11yMapValue
• a11yMapPDOMValue (for the PDOM-facing attributes only)

By having different APIs, we provide the least confusion and most ability to support the unique design cases that we have continually wanted for these two different interactions.

Tagging @pixelzoom, especially since I hope he will likely feel similarly, especially as it pertains to his most recent comment on the topic: https://github.com/phetsims/sun/issues/698#issuecomment-858775664

[zepumph]

A large portion of this issue is going to be teasing out potential regressions in current code. Right now, in my-solar-system, because of the use of keyboardStep (25) + constrainValue (map to nearest 25), you can be at 24, press keyup, and then end at 50. If a designer considers that a "feature" than it will be a regression to just have keyboardStep (which will result in a final value of 49). It isn't clear that is a regression to me, so we will likely want to be careful about how we review sims effected by this change.

[kathy-phet]

@arouinfar @terracoda - tagging you because am curious what you think. My instinct would be that design wise it would be more important for keyboard that hitting next "arrow" would just to a clean next value. But I could see having different constrain values for keyboard and mouse. Clean numbers seems pedagogically useful

[terracoda]

Here's what I said over in #703

@zepumph and @samreid will https://github.com/phetsims/sun/issues/837 support iOS VoiceOver users who double tap and hold to activate a slider and then drag the slider thumb (without lifting their finger) to change the value of the activated slider? A similar gesture would be desirable in our own custom gesture input that was designed/prototyped for haptic research in JT and GFLB.

People, especially those with low vision, do not use a single forms of input. They mix it up switching between discrete focus-based input (e.g., the keyboard) and non-discrete pointer-based input (e.g., mouse and touch).

Some forms of input are focus based (e.g., keyboard, iOS VoiceOver taps and swipes, switch) and some forms of input are pointer based (e.g., mouse, touch, joy stick, head pointer, camera input=hands for RaP and Quad).

Some forms of focus-based alternative input can have a mode that allows for non-discrete/pointer-like exploration (e.g., iOS VoiceOver's double tap-hold-drag, and our own custom gesture for JT and GFLB).

If we can generalize input without comprising customizable options for output, I think that would be really nice. For example, people using a mouse do not need the same Voicing output as people using a keyboard.

[terracoda]

In OL and RIAW, we rounded to clean numbers when using keyboard. I agree, clean numbers are pedagogically useful. I think we wrote about this in this 2018 HCII paper https://dl.acm.org/doi/abs/10.1007/978-3-319-92049-8_28

Maybe this link is better: https://link-springer-com.colorado.idm.oclc.org/chapter/10.1007/978-3-319-92049-8_28

[arouinfar]

I don't think I fully follow what's going on here @zepumph, but if the result is that constrainValue and keyboardStep will independently always take you to nice, round values, I'm all for it.

@arouinfar @terracoda - tagging you because am curious what you think. My instinct would be that design wise it would be more important for keyboard that hitting next "arrow" would just to a clean next value.

Agree!

But I could see having different constrain values for keyboard and mouse.

I would argue that 99% of the time we want constrainValue and keyboardStep to be exactly the same. In the sims I've designed with alt input, I've made sure to specify the same interval for both. If it's important to encounter the values in increments of 10, it shouldn't matter how you are using the slider.

Clean numbers seems pedagogically useful

Agree! We should prioritize clean numbers in all input forms.

[zepumph]

This feels like backburner alt-input work that I won't have time for now and may need more discussion before proceeding, but is good to recognize as a potential step forward.

We have already mentioned this in https://github.com/phetsims/scenery/issues/1298, and I think that will be where this work get's scheduled next, unassigning.

[samreid]

We confirmed the behavior in My Solar System is correctly quantizing as desired. So I don't have other planned work on this issue at the moment. Self-unassigning.

[jessegreenberg]

This came up for us again in greenhouse-effect. We tried constrainValue, found that it did not work for the shift key because of the workaround. We tried using a11yMapValue and it worked great. I would like to work on this next so that it doesn't cost more time in the future.