How to implement "Play area" and "control area" for scenes and games screens

[pixelzoom]

Related to https://github.com/phetsims/fourier-making-waves/issues/76... We're running into a problem with “play area” and “control area” for the Wave Game screen in Fourier. This problem is not specific to Fourier. It occurs for most game screens, and likely for screens with "scenes". I'm creating this issue in vegas mainly because I didn't know where else to put it, so feel free to transfer it to another repo.

In a typical screen, UI components are assigned to either the “play area” or the “control area”, but not both. Each screen has a ScreenView, and this assignment is implemented by adding UI components as children of the ScreenView’s playAreaNode or controlAreaNode.

A typical game screen transitions (animates) between 2 user interfaces: a set of level selection buttons, and one of N level. Let's call these user interfaces "scenes". In Fourier, there are 6 scenes: level-selecton buttons, Level 1, Level 2, Level 3, Level 4, Level 5. The animated transition is handled by TransitionNode.

Two problems:

(1) Only one of the scenes is visible at a time. They may each have their own logical “play area” and “control area”. And they are dynamically added and removed from the screen. (TransitionNode has an option to either change their visibility, or actually add/remove them from the scene graph.)

(2) The scenes must be children of TransitionNode. So it's impossible to add the UI components for each scene to playAreaNode or controlAreaNode. We could add TransitionNode to either playAreaNode or controlAreaNode, but then everything is either "play area" or "control area".

I suspect that this problem also extends to simulatons that have "scenes", like Equality Explorer, Number Line: Integers, etc. But I think that game screens are the most severe case.

Thoughts from the a11y team on how to proceed in general? For the long-term? For the short-term and Fourier?

I'll start by assigning to @jessegreenberg. Also assigning to @arouinfar, since she's responsible for the Fourier "play area" and "control area" specification in https://github.com/phetsims/fourier-making-waves/issues/76.

[pixelzoom]

I should note that since Fourier 1.0 will not have interactive descriptions, my understanding is that we could get away with deferring the "play area" vs "control area" design for 1.0, ignore playAreaNode and controlAreaNode, and just add everything directly to the ScreenView.

@jessegreenberg does that sound right? And does this have any impact on our ability to implement accessibleName?

[jessegreenberg]

Regarding the two issues in https://github.com/phetsims/vegas/issues/93#issue-916656382, I am hopeful that these are supported by pdomOrder and we won't have to change anything yet. pdomOrder doesn't just support changing the order of PDOM content for Node children, but it also supports creating a different hierarchy for the PDOM when we need. So we could take children from under TransitionNode and add them to the pdomOrder of the playAreaNode or controlAreaNode without changing the scene graph.

If that doesn't work out, I could imagine changes so we have a playAreaNode and controlAreaNode for each scene rather than each ScreenView.

does that sound right? And does this have any impact on our ability to implement accessibleName?

Yes, that is right. accessibleName implementation can be done separately from this. But it does add to the conversation about what we are OK with publishing. Do we want to publish a sim with accessible names where elements aren't categorized into a "Play Area" or "Control Area"? "Play Area" and "Control Area" still exist in the PDOM and will be empty but discoverable with a screen reader, is that OK?

[pixelzoom]

My understanding was that "play area" and "control area" are implemented by adding Nodes to pdomPlayAreaNode or pdomControlAreaNode in ScreenView. But what I think you're saying is that we would NOT do that, and instead just set the pdomOrder for pdomPlayAreaNode and pdomControlAreaNode Do I undestand that correctly? If so... That's interesting, but also a bit scary. That approach would probably address the ScreenView rendering-order issues that I brought up in https://github.com/phetsims/joist/issues/721.

[jessegreenberg]

Yes, that is correct. And I agree that pdomOrder would address points made in https://github.com/phetsims/joist/issues/721.

[pixelzoom]

From 6/10/21 Fourier meeting notes in https://github.com/phetsims/joist/issues/721#issuecomment-858981800:

@jessegreenberg suggested that, going forward, setting pdomOrder for pdomPlayAreaNode and pdomControlAreaNode is a better approach than addChild for those Nodes. @kathy-phet asked @jessegreenberg to make a PSA about this new approach for "play area" and "control area".

[pixelzoom]

Since we're not going to address "play area" and "control area" for Fourier 1.0, I'm going to unassign myself from this issue. But feel free to loop me back in if you'd like my input.