Make home screen accessible

[jessegreenberg]

The home screen should be accessible. This hasn't been an issue yet since most accessibility prototypes have been a single screen. Among other things, we will need to decide

• What does the screen reader say on loading into the home screen(see accessibility comments in Show progress indicator while JS loading #348 (comment))
• What is the keyboard interaction for screen buttons?
• What is the keyboard interaction for the navigation bar?

[jessegreenberg]

Removing my assignment for now, this is not going to be addressed until we begin accessibility work on a sim with multiple screens.

[jessegreenberg]

In phetsims/a11y-research#45 @terracoda and @melbanyard made a mockup for accessible content for the home screen. And we are nearly ready to work on keyboard nav in sims with multiple screens.

Here is the mockup:
http://htmlpreview.github.io/?https://github.com/phetsims/a11y-research/blob/master/html-sketches/sim-screens/template-sim-screen/00-home-screen.html

@zepumph would you mind working on this?

[zepumph]

I got started on this this afternoon. There is now keyboard nav on the screen buttons of the home screen. You can see the best progress in RPAL's a11y view, because I added screen descriptions for them also. Try it here http://phettest.colorado.edu/reactants-products-and-leftovers/reactants-products-and-leftovers-a11y-view.html?brand=phet

Here are some disjoint notes I took along the way.

• I implemented it so that each screen creates its own custom description. That way we wouldn't have it such that "Explore" would always be first, and "Investigate" would then be next.
• @jessegreenberg, how do you feel about me "overloading" accessibleDescription to be used in the model by Screen.js?
• If we do end up keeping the implementation where screen instances decide what their description will be, then perhaps we should add on a pattern to the end to always say "in screen X". Otherwise the screen has no context of what index it is at. Also do we just concat it on in HomeScreenView (sounds messy), or do we need to have each description adhere to the same pattern format (also sounds messy)
• I still need to export these into a "joistA11yStrings.js" file. But I thought that things may change, so I didn't want to quite yet.
• I don't yet know how to link the button and the button description with the "aria-describedby" attribute because currently the description is just the a11y mixin's description setter, not a different node (so both tags are controlled by the same node). I may have to change that.

[zepumph]

Have a look @terracoda @jessegreenberg and @melbanyard!

[terracoda]

@zepumph, great so far. I hear the list structure, and "Sim screen" aria-roledescription.

As per #355 (comment),

Re item 1
AT like screen readers, will just automatically start reading from the top of the page (Page Title, H1, intro P, UL and items, etc.), so I don't think we have to do anything specific to make it start reading, except provide the content.

Re item 2
I think the button should be in it's large selected state with the pink highlight when it gains keyboard focus. This would allow a non-visual user to activate the button only once to load a sim screen. The double activation really doesn't seem right to me for keyboard navigation.

Re item 3
I think in the navbar, the keyboard focused state should be the dimmed state with keyboard focus highlight before the button is activated and the bright state with keyboard highlight after the button is activated.

We may not need the "Sim Screens" label above the UL of sim screen buttons.

Is there a role=navigation on the ul?

[zepumph]

Discussion in keyboard navigation meeting today:
Tab to a small button should "click" it and activate the large button.

[zepumph]

Is there a role=navigation on the ul?

Just to be clear you want that role on the list, so the html will be:

<nav>
  <ol role='navigation'>
       <li>
       ......
   </ol>
</nav>

Also currently it is an ordered list, would you like it to unordered?

[terracoda]

@zepumph, sorry, I didn't hear anything about navigation on my quick test. If the nav element is there, that provides the navigation role natively. There is no need for role="navigation" on the ol.

[terracoda]

@zepumph, we are going with the ordered list to imply/encourage to do the screens in order.

[zepumph]

Great!

[zepumph]

In the below commit I updated the "select large button on tab" logic. @terracoda will you take a look on phettest.

I just thought of something else. Since we are using two different buttons that hold the same information, but switching them out, will that be confusing to non visual users? I notice that in the PDOM it is redrawing the entire accessibility div when we change button visibility. Will AT users be able to see these "two" buttons as one coherent source for information about the screen?

[terracoda]

@zepumph, the Tab interaction looks good, and mostly sounds good in Voice Over.

There is some strange focus behaviour when I make Voice Read from the beginning (Cmd-Option-B key). Visual keyboard focus moves with the virtual cursor (that might be normal), but VO stops reading randomly on the list items. Not sure if this has to do with redrawing of buttons. VO does not say why it is stopping. It would be nice if it did :-)

[zepumph]

but VO stops reading randomly on the list items.

Is there any insight you have on when it stops reading? I could imagine that it would stop reading when you switch from the first screen to the second, because when you do that interaction (tabing from the first screen, which is large and highlighted, to the second smaller one which then becomes large and highlighted) both buttons are removed from the PDOM and redrawn as the opposite button sizes with the same a11y content. This is probably bad business for AT interaction.

[terracoda]

@zepumph, no insight yet. Usually screen reader software just reads what is in the PDOM until I tell it to stop, or I do an interaction. However, in the case of the home screen, it just stops reading...a couple of times on the first button and a couple of times on the second button.

[zepumph]

Adding meeting label to talk about how the PDOM is redrawn when tabbing between large/small buttons.

[jessegreenberg]

@zepumph I expected this to be a problem but it sounds great with NVDA + Firefox.

[jessegreenberg]

11/9/17 - We are going to test with other screen readers and try to reproduce the case that @terracoda ran into with VoiceOver. From there it will be easier to figure out a workaround.

[zepumph]

@jessegreenberg I don't have access to voice over, but I agree that everything sounded good for me on NVDA + firefox/chrome. Let me know what else I can do.

[jessegreenberg]

I went ahead and checked off the items in the original ticket, those have been defined and implemented. Ill have a listen on VO to see if I can reproduce issues that @terracoda ran into.

[jessegreenberg]

It did stop for me at the second screen button with VoiceOver.

[samreid]

@jessegreenberg can you please comment on the status of this issue?

[jessegreenberg]

This can be closed, the remaining issue here was resolved in #683.