Scenery, nesting hierarchies and accessibility

[terracoda]

@jonathanolson, @jessegreenberg and I have been discussing the semantics of the the Sim's bottom bar in a few issues, but mainly in this one #25.

For accessibility, the hierarchical nature of HTML provides a reliable and robust way to create relationships between certain elements, and it does so quite easily.

For fuller code examples see example in #25 (comment), and #25 (comment)

Basically, we would like to be able to nest the list that PhET Menu button controls inside the bottom bar closer to the actual button:

<!-- Design pattern adapted from Pickering's menu button.-->
<nav aria-label="Sim tools and links">
  <button aria-expanded="false">PhET Menu</button>
  <ul hidden>
    <li>list of menu items</li>
  </ul>
</nav><!-- end PheT Menu Nav -->

In Scenery, we can't easily put the button and the hidden menu inside the nav element inside the parent bottom bar container.

ARIA features such as aria-controls are meant to create relationships between elements when there is not clear relationship in the DOM (PDOM in our case) in cases exactly like this; however, it is not yet well supported by AT. See the 2016 article, aria-controls is poop.

@emily-phet suggested I ask you about how difficult or easy it might be to build some more nesting capability into Scenery?

It would be nice to have your thoughts. No rush on this issue at the moment.

Do you have any thoughts on this?

[jessegreenberg]

Scenery handles nesting nicely, the difference in html is due to the sim structure set up in joist/Sim.js. We want the html in #32 (comment), but the Sim.js scene graph looks something like

<simulation>
  <screens>
  <navigation-bar>
    <phet-menu-button>
  <dialog-layer>
    <phet-menu>

So the accessible DOM will look something like

<div id='simulation'>
  <div id='screens'>...<div>
  <nav is='navigation-bar' aria-label="Sim tools and links">
    <button aria-expanded="false">PhET Menu</button>
  </nav>
  <div id='dialog-layer'>
    <ul id='phet-menu'>
      <li>list of menu items</li>
    </ul>
  </div>
</div>

We could presumably do some work in joist to change this, but before spending time it would be nice to know

• Why is the structure in the html example in Scenery, nesting hierarchies and accessibility #32 (comment) important for accessibility?
• What is different in the user experience between the two options?

[jessegreenberg]

The nav bar has been working well with the PDOM for a long time, so im not sure if anything needs to be done for this issue. But it is also possible that the requested structure in #32 (comment) possible after improvements to the ways we can set pdomOrder.

@terracoda can you please comment on whether this is still something you would like to work on?

[terracoda]

@jessegreenberg, this issue is over 4 years old, and we were likely just trying to figure out the structure of the navbar when this was opened.

If my memory is correct, I think there was some issues around the button and the menu because the popped up menu items were in a dialog.

I am not sure that's the case any more. I am also not sure we are using a nav element around the menu items.

I think you are likely correct, that this issue is no longer relevant. The structures we are using now are effective.

Maybe for clarity you could post the current HTML structure of the navbar?

[zepumph]

We have tackled the general structure of the simulation in the PDOM over in Joist. This issue is very old and I think the best path forward would be to close this.