Add alt input option for pH probe in the Macro screen to be a 2-step grab and drag

[pixelzoom]

In Slack#description-tooling, @terracoda said:

Regarding Alt Input for pHS + pHSB we need to also do the Probe, not just the Eye Dropper. While the probe currently has Alternative Input, it was never decided if a single-step or two-step grab was the ideal for the interaction, and I want to know if PhET has a floating probe design or a floating probe option because for non-visual access a floating probe could be ideal - your probe is in the beaker or out of the beaker.

[pixelzoom]

it was never decided if a single-step or two-step grab was the ideal for the interaction

When we added alt input to this sim, it was decided that a single-step grab was appropriate for interaction with the pH probe in the Macro screen. That is what we have been doing as a general rule in sims that do not have description, with the expectation that it will be revisited at a point in the future when description is added. Since we’re now adding description, it sounds like the time has come to revisit.

If we change to 2-step grab, this will involve adding keyboard help for the pH probe.

[pixelzoom]

Since ph-scale has multiple probes... It's my understanding that @terracoda is referring to this pH probe in the Macro screen:

[terracoda]

@pixelzoom, apologies for my strong language. Yes, single step grab okay for Alt Input, and my guess is that a two-step grab will support a wider audience of learners better now that we are adding description.

Thanks for pointing out that pH Scale has multiple probes, but I think the pH probe is the only draggable one.

While reviewing the sim with @arouinfar and @Nancy-Salpepi, we see the benefits of a non-floatable probe. A learner can place the probe at a few useful places:

• in the solution
• in the dispensing column of the dropper
• under the water faucet
• under the drain
• back in home position outside the beaker

We'll be considering shortcuts for these positions.

Until then, @pixelzoom is it possible for you to implement the two-step drag from common code, and to consult with @jessegreenberg if needed? And note that the grab help text is platform specific:

Platform-specific help text:

Alternative Input (Keyboard):

• Look for {{pH probe}} to play. Once grabbed, use keyboard shortcuts to move {{probe}}. Space to release.

Mobile IOS

• Double tap and hold to grab {{pH probe}}. Lift to release.

[terracoda]

Assigning to @pixelzoom for comment and/or implementation.

[pixelzoom]

Until then, @pixelzoom is it possible for you to implement the two-step drag from common code, and to consult with @jessegreenberg if needed?

@jessegreenberg can you point me to an exemplar in another sim?

And note that the grab help text is platform specific:

@terracoda @jessegreenberg Can you point me to another sim that has platform-specific help like this?

[pixelzoom]

At a separate alt input meeting, @terracoda mentioned that both 1-step and 2-step drag versions will be needed for interviews. The easiest way to select the drag type will via a (private) query parameter. Please let me know what you'd like the query parameter to be named, the values that it can take, and what the default value is.

[terracoda]

After discussions with @kathy-phet, we would like to take the opportunity to explore the accessibility of both interaction design patterns with learners.

@pixelzoom, we will need an option to turn the Grab-Drag interaction on for the Probe, rather than replace the current implementation.

The default behaviour can remain as-is, though it will need a slightly different approach to the description design (not part of this issue), and it will possibly need an aria-roledescription indicating the probe is movable.

The second option should be the two-step grab and drag interaction which I believe is in in common code. The help text for that interaction (if you are implementing the help text) should refer to the probe, and because it is a custom interaction there is a second version of the help text which is specifically for iOS VoiceOver. I am not sure what you need for implementation, so i will put both here.

Help text for pH Probe:
Alternative Input (Keyboard):

• Look for {{pH probe}} to play. Once grabbed, use keyboard shortcuts to move {{probe}}. Space to release.

iOS VoiceOver

• Double tap and hold to grab {{probe}}. Lift to release.

[terracoda]

And the query parameter could be something like, twoStepGrabDrag=true or just twoStepGrabDrag

Is that a good name for a query parameter?

[jessegreenberg]

can you point me to an exemplar in another sim?

The component is scenery-phet/GrabDragInteraction. There is a simple demo in scenery-phet/demoGrabDragInteraction. Another simple example is in faradays-law.

Can you point me to another sim that has platform-specific help like this?

I would recommend waiting on this. This is related to Interactive Description, not alt input. We will try to set this through the new description plugin prototype (#294).

[pixelzoom]

While the pH probe is the only draggable element in ph-scale-basics, ph-scale has other draggable things, specifically the H2O and OH indicators on the graph in the My Solution screen. So noting here that if we ultimately decide to go with GrabDragInteraction for the pH Probe, then we will have an inconsistency in the ph-scale sim --- some things will require 2-step drag, while others will not.

[pixelzoom]

And the query parameter could be something like, twoStepGrabDrag=true or just twoStepGrabDrag
Is that a good name for a query parameter?

"two step" seems redundant since "grab drag" is 2 steps. And as noted in #292 (comment), this applies only to the pH Probe, not to the other things that can be dragged in the sim. So I'm going to name the query parameter grabDragProbe, and its type will be 'flag'.

[pixelzoom]

I'm running into a problem with creating GrabDragInteraction conditionally (based on ?grabDragProbe). It must be PhET-iO instrumented, so if it is not created, the PhET-iO API is changed.

@jessegreenberg your recommendation?

Can I just do this for now?

new GrabDragInteraction( ... {
  ...
  tandem: Tandem.OPT_OUT
} );

[jessegreenberg]

Yes, opting out of PhET-iO seems reasonable for now while prototyping.

[pixelzoom]

With assistance from @jessegreenberg, the pH probe in the Macro screen now uses GrabDragInteraction when run with ?grabDragProbe. @terracoda @jessegreenberg please review and let me know if you'd like to change anything.

Note that I did not add keybord help related to GrabDragInteraction for the Macro screen. If we decide to move forward with using GrabDragInteraction, we'll need to do that. In the meantime, it seems like unncessary work, but let me know if you'd also like keyboard help to change based on ?grabDragProbe.

Also note that I encountered several serious problems with GrabDragInteraction, tracking in phetsims/scenery-phet#872. I managed to work around those problems, but it's not pretty. The workarounds are OK for prototyping the description plugin, but I highly recommended addressing phetsims/scenery-phet#872 before ph-scale or ph-scale-basics are published again.

[pixelzoom]

@jessegreenberg A reminder that we did not provide options objectToGrabString and idleStateAccessibleName to GrabDragListener. You said that those should be filled in via the description plugin, so they were omitted. I originally had something like this in MacroPHMeterProbe.ts:

const grabDragInteraction = new GrabDragInteraction( this, keyboardDragListener, {
  objectToGrabString: 'probe',
  idleStateAccessibleName: 'grab probe',

[pixelzoom]

@terracoda @jessegreenberg a reminder that this has been ready-for-review since 9/18/24. Assign back to me if you have feedback or requests that require further work.

[terracoda]

Been working on description. Reviewing now.

[terracoda]

The keyboard interactions all work nicely. Thanks!

We need to add to the description context in order to add description for both interactions in the description tool.

@jessegreenberg will take care of this and show you the commit.

[pixelzoom]

In today's planning meeting, @terracoda was unclear about why @arouinfar and I are blocked on this issue. Here's what still needs to be done:

• @jessegreenberg is assigned to this issue and needs to review how GrabDragInteraction was integrated into the code.
• As I understood it, 2-step drag was added so that designers could compare 2-step vs 1-step in interviews. Those interviews need to happen (who is doing the interviews?). Interview results will determine which drag implementation to keep in the code -- there are currently 2 implementation, 1 of which is intended to be deleted, along with the grabDragProbe query parameter.
• If 2-step drag is chosen as the method to keep, then a mockup of the associated keyboard help text is needed. @arouinfar will likely be involved in that design.
• If 2-step drag is chosen, it will affect both ph-scale and ph-scale-basics. ph-scale has other draggable objects, and we will need to consider whether they should also be 2-step for consistency. @arouinfar will likely be involved in that decision.

Assign back to me when I can continue.