should Checkbox and AquaRadioButton pointer areas fill width of containing panel?

[samreid]

As identified in phetsims/wave-interference#112, some simulations are set up so that the touch areas for Checkboxes or AquaRadioButtons extend to the right to the width of the widest component (for components of the same kind). There are exceptions to this rule, such as Acid Base Solutions:

Generally, I think it would be a good user interface paradigm to extend the mouse and touch areas of those components all the way to the right, as we have done for simulations like Forces and Motion: Basics:

Though I noted that even this sim doesn't have the touch areas span the full width in some screens:

This is because the naive implementation of VerticalCheckBoxGroup and VerticalAquaRadioButtonGroup only extend to the widest member of that group, not to the width of the containing panel.

I was interested in getting this feature for Wave Interference, which currently looks like this:

But I wanted to make sure we are able to do so in a robust and uniform way, with support from common code and minimal simulation-specific logic. I do not expect us to have a robust and uniform solution in time to publish Wave Interference, but I've asked if that is necessary in this comment: phetsims/wave-interference#112 (comment)

We should discuss with @ariel-phet and our design team about whether we want to address this, and discuss with @ariel-phet what the priority should be, and who should be involved in the development. We may need to have one or more development meeting discussions about the best way to implement this, and it probably relates to our desire to have better support for general layout engines. I'll assign to @ariel-phet for now, and he can escalate to design meeting/developer meeting or other discussions as necessary.

[ariel-phet]

I am going to mark for dev meeting currently. So far, I don't recall this issue being a problem, so are we trying to fix something that does not really need fixing?

[pixelzoom]

My opinion is that this is a non-issue. And what @samreid has suggested may actually result in more unintended "hits" on UI components. Yes, iOS settings work this way, but the context is very different.

[samreid]

I've seen web forms where the touch areas of adjacent buttons don't match up, and it is a poor user experience (seems buggy). Also, the ARIA Radio Button Group example at https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/examples/radio/radio.html has the touch areas uniformly expand far to the right (some may say too far!)

[pixelzoom]

Why would you ever do that in a sim context?

[samreid]

Why would you ever do that in a sim context?

Can you clarify? Here's a sim context with vertically stacked buttons where the touch area spans to the right of the containing panel. Should we purposefully redesign it to stagger it?

[pixelzoom]

I doubt that anyone would ever expect to click at the far right of the control panel in order to select the Mass checkbox. Users will typically click on the checkbox or the checkbox's label. So again, imo a non-issue for quality of UX.

Your example (MotionControlPanel) also demonstrates an anti-pattern for implementation. Your sim is responsible for the uniform pointerArea widths, and the implementation is significantly more complicated because of it. If this is something that we're going to do uniformly, then it should be supported by the common-code container -- not the UI components, and certainly not the sim.

[samreid]

Your sim is responsible for the uniform pointerArea widths

This is actually handled by common code, see VerticalCheckboxGroup.js

[jonathanolson]

Notably I've always expected checkboxes/radio buttons to work that way, and in many UIs they seem to. I feel fairly strongly that the expanded mouse/touch areas (to the right) is helpful.

[pixelzoom]

This is actually handled by common code, see VerticalCheckboxGroup.js

And if my control panel doesn't consist entirely of checkboxes?

[samreid]

At developer meeting: We reviewed the data in Capacitor Lab: Basics and found it was rare that clicks occurred outside of a particular label. We decided where it is trivial and doesn't cause further interference, like in cases like #399 (comment) that we will accept the aligned touch areas (and not go back to try to stagger it). But that it isn't worth additional effort to try to align them in other cases (unless accessibility or mobile usage is a concern.)

[phet-steele]

Did we take keyboard nav into account for this discussion? I only have a hunch that the bounds for a focus highlight depend on the pointer areas of these labels. Certainly correct me if I'm wrong and close this issue again.

I think extending the pointer areas bounds looks better...

...than not:

[jessegreenberg]

Good point @phet-steele, I agree first gif in #399 (comment) looks nicer. The focus highlights are not dependent on the pointer areas, but on bounds. So by default, the focus highlight and touch areas will be similar, but they can be changed independently.

[samreid]

If we decide to align the bounds so the focus highlights line up, then we should set the pointer areas to match those bounds.

[pixelzoom]

@samreid said:

If we decide to align the bounds so the focus highlights line up, then we should set the pointer areas to match those bounds.

I'm confused... Don't pointer areas default to bounds? And we certainly don't want to set pointer areas, then expand bounds.

If we're going to expand pointer areas or bounds to have uniform widths, that should be handled by the containers, not client code.

[zepumph]

Discussed this briefly today in developer meeting, but quickly decided that we should have @ariel-phet present, especially since he was instrumental in determining that this was not worth the time to change.

Let's talk next week with @ariel-phet.

In the mean time @jessegreenberg and @zepumph will bring this up with @emily-phet and @terracoda at accessibility meetings to see what their design opinions are on the matter.

[emily-phet]

Some thoughts for next a11y meeting - Focus highlight alignment is needed, though not sure what bearing this has on final decisions for this issue. Is it the case that in sims we've already instrumented with keyboard that the developer was just going through and manually setting the bounds so that all the focus highlights lined up? How have we gotten alignment so far?

[jessegreenberg]

Discussed with @emily-phet and @terracoda. Components are generally more accessible if their touch areas are increased. There was agreement that consistently sized focus highlights look better, and we will want focus highlights to look like the top example in #399 (comment). As focus highlights change, it will be important that the pointer areas match the extended focus highlight.

@emily-phet mentioned that for a11y this doesn't necessarily need to be done eagerly, but can be done as part of the a11y instrumentation process when we revisit each sim.

[samreid]

See also #384 for a strategy that support this feature.

[samreid]

We discussed the possibility of using AlignGroup to set up these bounds--that would work across different control panels.

We also discussed that this is generally a difficult problem and it is unlikely for us to have perfect common code support for it--simulations themselves will likely need to address this.

If/when we investigate automatic layouts, we should investigate this at the same time.

@jonathanolson points out that AlignGroup may be able to handle setting pointer areas or a11y focus areas.

[samreid]

@emily-phet we discussed this at today's developer meeting and there doesn't seem to be a tractable way to support aligned components in general. Can you please review https://phet-dev.colorado.edu/html/graphing-quadratics/1.0.0-dev.46/phet/graphing-quadratics_all_phet.html?showPointerAreas&accessibility and comment on whether it is acceptable or if it should be corrected before publication? If it's not acceptable, please clarify why and what is the minimum change that can give it an acceptable behavior.

We also wanted to clarify that the movie in #399 (comment) is no longer accurate, so that's why we wanted to point you to graphing quadratic (with pointer areas and ?accessibility) for your investigation.

[emily-phet]

Thoughts:

• From prior conversations with @jessegreenberg and @zepumph, we discussed aligning focus highlights and mouse/touch areas to align as the sim is published with full alternative input. It seemed like it would be nice for these to default to the same alignment, but it that's not possible we've already been doing that sim-by-sim, so presumably we could continue doing that.

• for the Graphing Quadratics sim, is the intent that it is published with alternative input? If so,

1. the little X,Y indicators on each screen would each need to be implemented as 4-way draggable objects
2. it would need keyboard access to the moveable points on the graph in the last two screens (presumably as vertical sliders)
3. the focus highlights would need to align
4. we'd need a check of the focus order
5. we'd need a keyboard help dialog created and implemented

I believe (though @jessegreenberg and @terracoda can confirm) that collectively we know how to do all of these things, it's just a matter of time and knowledge sharing to do them. We may be at the point where the time and effort required is relatively low.

• if it is not the intent to publish Graphing Quadratics with keyboard navigation, I'm not sure what the question is for me. It wouldn't matter what the focus highlights look like...

[jessegreenberg]

graphing-quadratics is not being published with alternative input so nothing immediate needs to be done for this issue.

It was discussed in developer meeting that we have gotten focus and pointer area alignment in a11y sims we have worked on thus far because they are using things like VerticalAquaRadioButtonGroup, types that have knowledge of all inputs in the set to align focus and pointer areas.

But not all PhET control panels use these types, in this issue benefits for not using these were listed.

Another reason this is complicated is because PhET controls occasionally mix check boxes, radio buttons, and others and sometimes with indentation or any other arbitrary layout.

So handling this in a scalable and consistent way would take significant effort.

[pixelzoom]

In #399 (comment), @emily-phet said:

It seemed like it would be nice for these to default to the same alignment, but it that's not possible we've already been doing that sim-by-sim, so presumably we could continue doing that.

Doing this on a sim-by-sim basis is not recommended - it increases the time/cost for every sim, and makes it much more difficult to test/maintain/modify. If alignment is a requirement, PhET should incur the cost of handling it uniformly in common code.

[pixelzoom]

And to be totally honest, there's one other big drawback to doing this on a sim-by-sim basis. It's not at all interesting, solving the same problem repeatedly, busy work -- and that makes programming less fun. And that's one of the reasons that we endeavor to put things like this in common code; so we can do the not-so-fun things once, then get back to the fun stuff. I'm sure that other developers would agree with me on this.

[emily-phet]

@pixelzoom I am not at all advocating for a sim-by-sim approach. I am merely saying it is fine with me to proceed this way if necessary.

[samreid]

This issue came up in phetsims/wave-interference#438, is there a consensus for this issue? Anything else to do before this issue can be closed?