search

phetsims / a11y-research

a repository to track PhETs research into accessibility, or "a11y" for short
MIT License
3 stars 0 forks source link

A11y semantics for home screen and bottom navigation bar #45

Closed terracoda closed 7 years ago

terracoda commented 7 years ago

@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 thearia toolbar role for the bottom bar and not a the region role as discussed earlier.

Using Build and Atom as an Example:

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

terracoda commented 7 years ago

@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

Atom Screen

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

Other ideas:

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 commented 7 years ago

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 commented 7 years ago

@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:

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:

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?

emily-phet commented 7 years ago

Chiming in @terracoda latest iteration of @melbanyard descriptions:

1) Atom, button/sim screen:

2) Symbol, button/sim screen:

(notes:

3) Game, button/sim screen:

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 commented 7 years ago

@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:

terracoda commented 7 years ago

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

jessegreenberg commented 7 years ago

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

terracoda commented 7 years ago

@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 commented 7 years ago

Sounds good, thanks!

melbanyard commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

Will do @terracoda ! Thanks :)

melbanyard commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

@melbanyard, thanks Mel!

terracoda commented 7 years ago

@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:

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

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 commented 7 years ago

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

jessegreenberg commented 7 years ago

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

terracoda commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

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

terracoda commented 7 years ago

Reading on using nav element and lists:

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 commented 7 years ago

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

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

melbanyard commented 7 years ago

@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 commented 7 years ago

@jessegreenberg, @zepumph, I tested the Home Screen and Navigation Templates noted in comment https://github.com/phetsims/a11y-research/issues/45#issue-244437912 and here is what I noticed:

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

jessegreenberg commented 7 years ago

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

jessegreenberg commented 7 years ago

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

jessegreenberg commented 7 years ago

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 commented 7 years ago

@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 commented 7 years ago

@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 commented 7 years ago

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 commented 7 years ago

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

jessegreenberg commented 7 years ago

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

zepumph commented 7 years ago

@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.