A11y semantics for home screen and bottom navigation bar

[terracoda]

@emily-phet and @melbanyard met yesterday to discuss the related interaction between the home screen and the bottom navigation bar in multi-screen sims. We need to think about the home screen, multi-screen sims, and the bottom navigation bar together to see how to optimize the interaction for multiple screen sims.

I mocked up two not so clean html pages representing the Home screen and the Atom screen for Build an Atom. The Atom screen is using the the aria toolbar role for the bottom bar and not a the region role as discussed earlier.

Using Build and Atom as an Example:

• Home Screen
• Atom Screen

Unfortunately, the sample toolbar.js did not work for me out of the box, and the toolbar.css is not loading. I will need help to get a real sample toolbar interaction implemented.

You have to tab through the buttons in the examples. There is no special tab index management working.

This issue is related to issue #25.

Using a template for an example

• Home Screen Template
• Screen One Template

[terracoda]

@melbanyard, I made a few commits the final one being:
f3a2d0d

I tested this version in Voice Over and the regions, headings, labels, button descriptions, and sim screen roles are all recognized correctly. To see and hear the regions and region names, I had to use the Voice Over rotor tool.

Features added to this version are:
Home Screen

• DRAFT text for Intro paragraph introducing the sim.
• nav element with the aria-label="Sim Screens" providing a named navigation region
• un-ordered list with three buttons, one to each of the sim screens.
• the three sim screen buttons have DRAFT aria-describedby content that is read out automatically with the button labels.
• the three sim screen buttons also each have an aria-attribute role-description="Sim Screen". With this aria-attribute, assistive technology reads out "Atom, Sim Screen" instead of "Atom, button" making it very clear what the role of the button is! I tested in Voice Over and it sounds great!

Atom Screen

• container for bottom bar is a generic div element with role="region" and the aria-label="Sim screens, resources, and tools."
• nested nav element with the same aria-label as the home screen, "Sim Screens".
• sim screen buttons have the same description, but it is provided without the aria-describedby attribute making it accessible "on-demand" rather than read out "automatically."
• the aria-roledescription="Sim Screen" provides a more explicit description of the role of the element as it does on the home screen.

The DRAFT text is just that. I eagerly await @melbanyard's descriptions.

Other ideas:

• We could use an ordered list for the sim screen buttons. This would more explicitly suggest, but not enforce, an order for accessing the sim screens.
• We could remove "On-demand" help text descriptions all together on the buttons in the navigation bar if people think it is not needed beyond the home screen. I think it is nice to provide it automatically (if brief) on the Home Screen, and then "on-demand" in the navigation bar.
• We could use headings with aria-labelledby attributes instead of some of the aria-label attributes to provide the region names.

With this structure, the interactive elements on the Home Screen and in the navigation bar, i.e., the buttons, are accessed with the Tab key (and of course the down arrow reading cursor key). The menu items in the PhET Menu, once popped up are clearly identified as menu items in a menu and would follow the interaction pattern of a menu.

[melbanyard]

Hi @terracoda (& @emily-phet)

Here are a couple passes I took for the sim descriptions. I'd love to hear your feedback so i can see what needs to be tweaked in order for us to move in the right direction.

Atom:
v1) The Atom Simulation allows for experimentation with protons, neutrons, electrons.
v2) Play with protons, neutrons, and elections in the atom Sim.
v3) Experiment with charge and mass in the Atom Simulation.

Symbol:
v1) The Symbol Simulation allows players to build elements.
v2) Build elements in the Symbol Simulation.
(I understand that symbol isn't just about "building an element", but I wonder how I can further explain this while still keeping it short).

Game:
v1) The Game Simulation lets players test their atom knowledge.
v2) Test your knowledge in the Game Simulation.

[terracoda]

@melbanyard, nice. Play, build, experiment, explore, and test are all good verbs. Verbs are important as they engage the user!

One thing to keep in mind is the other stuff that the screen reader says. You can't be exactly sure as it varies, but the screen reader will read out the label text and the the type of control/element it is. In this case, a native "button" with a possible role description replacement to "sim screen". We can try to be even shorter if we think about what the screen reader provides by default.

I don't think we need the word simulation. The user gets that from the page title, and plus all the screens together make up a single simulation called "Build and Atom." "Sim screen" could be provided in place if "button" in the ideal case, so then we want to still with the essentials of the learning goals in the screen.

For example, given option 2 for the first screen, it might sound like this:

• Atom, button. Play with protons, neutrons, and electrons in the atom sim.

Or in the ideal case with the correct reading of the aria-roledescription attribute, the word sim screen is provided automatically, so you might want to adjust it like this:

• Atom, Sim Screen. Play with protons, neutrons, and electrons in an atom.

I think the pedagogical focus in Screen 1 learning about what makes up an atom. For screen 2, it is assumed students are masters of screen 1 and they now turn their focus the periodic symbol that represent an atom, and how it changes as the atom changes. In screen 3, it is an assessment game, so "Testing knowledge" is definitely key there.

Keeping your descriptions in mind, the main pedagogical goals, and trying to keep it under "7" words... here's what I came up with:

1. Atom, button/sim screen:

• Play with what makes up an atom, or
• Play with particles that make up an atom.

2. Symbol, button/sim screen:

• Explore symbols that represent atoms, or
• Explore periodic symbols that represent atoms.

3. Game, button/sim screen:

• Test your knowledge of atoms and symbols.

What do you think?
And how do you feel about a welcoming short paragraph?

• Come play with Build an Atom. It has three screens.

[emily-phet]

Chiming in @terracoda latest iteration of @melbanyard descriptions:

1. Atom, button/sim screen:

• Explore what makes up an atom
  (notes:
• I think we want to be careful about use of the word "play" for sims that definitely span into college level (don't want to turn off teachers or students by sounding potentially to childish). I think play is great to use in the sim descriptions, but perhaps very sparingly. So I'm suggesting we replace this one with "explore".

2. Symbol, button/sim screen:

• Investigate atoms and their atomic symbols

(notes:

• What do you all think about replacing "explore" here with "investigate"? Atomic symbols is a bit more of a advanced topic than just a basic intro to protons, neutrons, and electrons, so I don't think "investigate" will sound too intimidating for anyone making serious use of this screen. We could just have two descriptions that start with "explore".

• the symbol representation in the symbol screen is technically the atomic symbol. We do shorten this to symbol for the screen name (mostly so it fits nicely in the nav bar) but for some reason it reads a little odd to me to just say "symbol" in a sentence. So let's go with "atomic symbol".)

3. Game, button/sim screen:

• Test your knowledge of atoms and atomic symbols.

I like your idea for the short intro paragraph. With the same concern about potential overuse of play, I'm suggesting we replace "play" with "explore" here. (man I wish there were more playful synonyms for "explore". :)

Come explore with Build an Atom. It has three screens.

[terracoda]

@emily-phet, I like "investigate", and totally agree with not over using "play". I wanted to use "explore" for the first one, but was trying to avoid 2 "explores" in a row in the screen list. I also like the repetition of "atom" in the second option as they are still exploring the atom, though the focus has switched to the "atomic symbol".

To summarize:

Intro para:
"Come explore with Build an Atom. It has three screens."

Screen list buttons with accompanying help text:

1. Atom, button/sim screen:

• Explore what makes up an atom.

2. Symbol, button/sim screen:

• Investigate atoms and their atomic symbols.

3. Game, button/sim screen:

• Test your knowledge of atoms and atomic symbols.

Other potential verbs to think about for sim use may be:

• examine
• experiment

[terracoda]

Commit 75117ea adds the new content and changes the un-ordered sim screen list to an ordered list.

[jessegreenberg]

@terracoda I am wondering if we use "Sim Screen" as the aria-roledescription here, will users know to activate it like a button?

[terracoda]

@jessegreenberg, great question, and I am confident the answer is "Yes"! However, we do need to fully test how things are handled by different AT.

I'm not sure what NVDA and JAWS do, but VoiceOver provides the same help text instructions as it would for a button, but replaces the word, "button" with "Sim Screen". The element still has the role, button, it is just described as a "Sim Screen".

I think it would be useful to test that screen reader hot keys that help identify buttons, such as the B key in JAWS would still identify the control as a button.

[jessegreenberg]

Sounds good, thanks!

[melbanyard]

Sorry - fell off due to work obligations over the past few days. I'd like to have some revised descriptions for this Friday's meeting, so we can discuss them live. Will take all this feedback into account. Thanks @terracoda @emily-phet @jessegreenberg :)

[terracoda]

No worries @melbanyard. Have a look at Emily's suggestions, I've implemented them in the HTML mock-ups to make it easy to review.

[melbanyard]

Will do @terracoda ! Thanks :)

[melbanyard]

PhET_KeyboardNav_BuildanAtom_v3.pdf

@terracoda @emily-phet hello! Please take a look at how I've implemented the descriptions discussed above into the first screen of build an atom. :)

[melbanyard]

PhET_KeyboardNav_BuildanAtom_v4.pdf

@terracoda @emily-phet Did a quick pass this morning on the home screen mockups to thicken and adjust the highlight interaction.

[terracoda]

@melbanyard, the items look nice with the tighter focus highlight.
The homepage content itself is not actually focusable with the keyboard, so I don't think you need a focus highlight on the first slide in your mockup. I think the first focus highlight will be on the first item (i.e., first screen). I think the item gets focus by default as it is the first focusable item on the page.

[melbanyard]

@terracoda @emily-phet I took some time to carve off another little bit of the nav for Build an Atom, you can view it on the attached file. One thought I had - is it possible to remove the home button option on the bottom nav altogether? It seems redundant, since all the options presented to users on the home/welcome page are already in the bottom nav. I can't remember if I've mentioned this before.
PhET_KeyboardNav_BuildanAtom_v5.pdf

[terracoda]

@melbanyard, thanks Mel!

[terracoda]

@melbanyard, I like the home screen focus highlights. The screen items ones need to be a bit tighter.

My idea for the sim screen buttons was to have the descriptive help text read out automatically for the buttons on the home screen, but available "on-demand" for the sim screen buttons in the bottom navbar once a screen is loaded.

By available "on-demand", I mean the text is still there, but only accessible with the user uses the reading cursor keys to read it out. What would be read out on a screen switch would be the label text for the sim screen buttons and the role of the element (tab, button, menuitem), or the description of the button using aria-rolesdescription (Sim Screen, or Sim Screen button).

For example, the if the button are marked up in an ordered list, and the buttons are given aria-roledescription="Sim Screen" they would sound kind of like this in Voice Over with the Tab key:

• "Atom"
• "Symbol"
• "Game"
• "Home"

And if you read through the items with the cursor keys you would get more information:

• "Sim Screen 1, Atom"
  • "Explore what makes up an atom"
• "Sim Screen 2, Symbol"
  • "Investigate atoms and their atomic symbols."
• etc.

And then if the user explores further on any one o the items, they would get the more explanatory help text for the screen.

The home screen if marked-up properly, I think the a VO user would get the label, the role description and the help text together when navigating with the Tab key. My Home screen html mock-up is not currently working like that, though.

[terracoda]

Just sharing @melbanyard 's latest version here in the thread.
PhET_KeyboardNav_BuildanAtom_v6.pdf

[jessegreenberg]

Thanks @terracoda and @melbanyard! Does the pink highlight in the first slide mean that the whole screen is in the focus order?

[terracoda]

That's a good question, @jessegreenberg! I was going to ask @melbanyard about that, too.

Normally, is keyboard focus set on page load? Or is it just that the virtual cursor is placed at the top of the page, and no keyboard focus is set?

[jessegreenberg]

Normally, is keyboard focus set on page load? Or is it just that the virtual cursor is placed at the top of the page, and no keyboard focus is set?

At the moment, we are just letting the AT do what it wants with focus so the virtual cursor is just placed at the top.

[terracoda]

OK, good. That makes sense to me. It's just a bit confusing on the home screen, since one sim is already visually highlighted to encourage going there first, but it does not actually have keyboard focus.

Not sure if having a page highlight would be more clear for visual keyboard users. Let's see what @melbanyard and @emily-phet think.

I don't think we need that first big page highlight.

[melbanyard]

Hi @terracoda & @jessegreenberg

So I believe that first page in the PDF should have been removed prior to uploading (my fault). Earlier in our process Taliesin mentioned that there wouldnt be any focussed required when initially opening the page. So Jesse is right in stating that we're going to let the AT do what it wants when the page is first opened.

[melbanyard]

@terracoda Would you be able to share the content navigation of the sim in the google doc you mentioned in an earlier email to me?

[terracoda]

@melbanyard, I have shared the folder with you and sent you an email.

[terracoda]

Reading on using nav element and lists:

• Navigation Lists: To Be to Not To Be
• Wrapup of Navigation in Lists
• Leave Web Accessibility to the Experts

Summary
Seems lists are quite useful for providing semantics and a count, though different AT handle them slightly differently. The best part of all these articles is the comments.

[terracoda]

@jessegreenberg and @melbanyard, I edited the first comment to include links to a generic template version. The HTMLl is valid. The structure contains

• role region and a heading for the bottom bar. The heading will be placed in a page outline by AT.
• the current heading for the bottom bar is "Sim Screens, Resources, and Tools" for multi-screen sims and "Sim Resources and Tools" for single screen sims.
• A nav element surrounds the list of sim screen buttons. This should create a navigation region for the important sim screen buttons. The nav has an identifying aria-label, "Sim Screens"
• the buttons are in an ordered list that provides extra count information for AT that provides this useful information.

I think this is a solid semantic approach worthy for testing within a sim.

[melbanyard]

@terracoda The comments are great on these articles, and after reading them I have to agree that it sounds like lists will be the best way to go.

Is there any way you'd like me to apply these changes to the sim? Or can they be implemented right into a prototype at this point, rather than my PDFs.

[terracoda]

@jessegreenberg, @zepumph, I tested the Home Screen and Navigation Templates noted in comment #45 (comment) and here is what I noticed:

• Except for the items in the PhET menu, the two pages sound good in Voice Over.
• The markup sounds better with an ordered list than with no ordered list inside the nav element (VO says navigation region 3 items with list, and navigation region 6 items with no list structure)
• I think the items in the PhET menu need some work to make them operable with the Arrow keys? Not sure why they are not working as is? Not sure why role menu and role menu item are not providing semantics. However, this part of the bottom navigation bar may already be working in JT, so we can look at that code.

I can review with screen reader user next week, too.

[jessegreenberg]

Thanks @terracoda Ill give a listen with NVDA and JAWS.

[jessegreenberg]

Sounds great to me, pretty straight forward! @terracoda @melbanyard, just a couple questions about the numbers:

• Numbers are spelled in full, is it OK if we just provided numbers '3' instead of 'three'?
• Why are screens labelled with numbers '01' instead of just '1', we should never have 10 screens?

[jessegreenberg]

I think the items in the PhET menu need some work to make them operable with the Arrow keys? Not sure why they are not working as is? Not sure why role menu and role menu item are not providing semantics.

That would require JavaScript, the browser/AT doesn't include keyboard navigation from ARIA alone.

[terracoda]

@melbanyard, sorry I missed your comment https://cuboulder.zoom.us/j/221920770. I think your mock-ups are fine. They match pretty closely what with go under the hood.

[terracoda]

@jessegreenberg, the numbers are just place holder content in the templates. Theere will be no numbers on the actual labels for the screen buttons. The screen buttons on sims have their own names :-) See Build an Atom as an example. The list items are number naturally through their structure, but not the buttons.

Make sense?

[jessegreenberg]

Thanks @terracoda, makes sense. And what about things like

It has three screens.

Ok if we use '3' instead of 'three'? It would be quite a bit easier if we don't have to map numbers to translatable strings.

[terracoda]

@jessegreenberg, I hadn't thought about translation. '3' should work instead of 'three' for number of screens.

[jessegreenberg]

Great, thanks! Lets give it a shot in joist!

[zepumph]

@terracoda @melbanyard thank you guys for the design work here. Implementation issues for the HomeScreen and Nav bar are listed above as separate issues. Closing this long but productive issue.