Design of Popup Dialogue for Keyboard Nav Help

[emily-phet]

We need to design the dialogue popup that will inform users of the keyboard presses available for using the sim.

Here's the list of keyboard presses and actions (from Jon H.):

• Right Arrow and Up Arrow: Increase the value of the slider.
• Left Arrow and Down Arrow: Decrease the value of the slider.
• Home and End: Set the slider to the first and last values of the slider.
• Tab: Moves focus into and out of the slider.
• Page Up and Page Down (Optional): Increment or decrement the slider by an amount larger than the step changes made by the arrow keys.

There also will probably be a shortcut key to bring up this "help" info.

@arouinfar - can you mockup a popup box, similar to @terracoda 's mockups for BASE? (Ideally before the Thanksiving break). Note: all the key presses in JT are "standard", unlike in BASE, so JT's popup will be much simpler.

[terracoda]

@arouinfar, I'm sure you can make it look better than my original mock-up :-)

[arouinfar]

@emily-phet I can work on this later this afternoon (depending on how long it takes to get through the Google Drive migration) or Monday.

@terracoda your mockup is a really helpful place to start. :)

[arouinfar]

@emily-phet I've made a few (wireframe) iterations of the keyboard popup, which you can view in
Keyboard_Shortcut.pdf. I've included some comments to the .pdf file.

I prefer the last mockup in the file (pasted below). It groups the keys into categories, which I think will be a useful paradigm for other sims, as @terracoda's initial mockups have indicated.

@emily-phet please let me know your thoughts. I can polish up the mockups a bit more once I get some general layout/content feedback.

[jobara]

@arouinfar one of the tricky things with the JT sim is the circular motion of the appendages. Basically the ↑doesn't always move the hand/foot up visually. Consider the case where the leg is all the way back, pushing ↑ will actually make the foot look like it's going down.

[arouinfar]

pushing ↑ will actually make the foot look like it's going down

Excellent point @jobara. I struggled a bit with how to describe the motion because the hand and foot sometimes seem discrepant.

I'm hesitant to describe anything as a "slider" (even though it simplifies the text to some extent) because it seems like a nitty-gritty implementation detail that doesn't need to be revealed to the user. @jessegreenberg has pointed out that the screen reader refers to the hand/foot as a slider, but not everyone using keyboard navigation would also be using a screen reader.

I'm also wondering about the choice of home/end and page up/page down. These are Windows-specific keys. Within the sim, the Mac equivalents would be

• fn + up = page up
• fn + down = page down
• fn + left = home
• fn + right = end

Will Mac users be able to translate the keys themselves, or do we need to have a separate Mac help menu popup? I'm not overly confident about the former, because cmd+arrows can at times act like fn+arrows, depending on the context/application.

[arouinfar]

What I've been calling up/down works nicely for the hand, but the foot is different as @jobara has pointed out. Here's an alternative:

[jhung]

@arouinfar and @emily-phet, I made a quick sketch. Because of the issue @jobara mentioned I think we can avoid the confusion by simplifying and grouping the text (see the sketch).

I think it's okay to not be too specific in wording - we've observed that users are quick to figure out which direction they want to go after the initial key press (even if the key press moves the arm/leg in a direction they weren't expecting).

The way I see it, the home/end and pgup / pgdn keys aren't really important. They're convenient if you need them, but most cases users will be using up/down or left/right.

Edit: To clarify my last point - I meant to ask whether it's worthwhile to even mention the Home/End, and PgUp/Dn keys. It's not critical to using the sim. Thoughts?

[jobara]

@arouinfar and @jhung, the home/end and pgUp/Dn keys are not critical. They are features we just get for free with the slider.

@arouinfar you make an interesting point about key name. I suppose it's keyboard dependent as I still use an Apple keyboard that has home/end and pageUp/Dn keys, although this is becoming more and more uncommon. I wonder if there are PC laptops with similar key combination requirements too. However, the user may know or easily discover how to do those actions.

[arouinfar]

@jhung thanks for the sketch! It's really helpful.

@jobara I'll mock up a few more alternatives based on @jhung's sketch, both with and without the home/end and page up/down keys. I compared keyboards with a coworker who uses a small Dell laptop, and she also needs to use the fn + arrow keys. However, her arrow keys look something like this:

[terracoda]

@arouinfar, @jhung, @jobara, I also think Jon's approach is a nice one. I suggest the wording name the actual keys in the description, so it is clear for both visual and non-visual users. The actual images can then have blank alt text in the underlying HTML making them invisible to a screen reader user, thus making the reading experience more pleasant.

For example:
Left and right arrows keys move the foot and hand a small amount.
Tab key moves to next item.
Shift plus Tab moves to previous item.

Could add "in opposite directions" for the arrow keys if you think that is helpful, but that should be obvious (implicit and intuitive) with arrow keys.

Also as @jhung mentioned, no need for "closer to door" as the foot rubs forward and back on the rug and the hand moves more explicitly towards the metal doorknob.

Also, I don't think the word "focus" is necessary. The student has to have focus on the control to operate it.

[arouinfar]

Thanks for these suggestions @terracoda.

Could add "in opposite directions" for the arrow keys if you think that is helpful, but that should be obvious (implicit and intuitive) with arrow keys.

I agree that this should be obvious, though it could quickly be observed by visual users. However, would it be helpful to non-visual users to add "in opposite directions"?

Here are a few mockups that combine @jhung's sketch with @terracoda's text suggestions. The first is a more verbose, and the second more minimal. I could make an argument for either.

I'm also wondering if it's necessary to include instructions for the Tab and Shift+Tab commands. Aren't these standard in keyboard navigation?

[terracoda]

@arouinfar, yes Tab and Shift Tab very common keyboard operations. They would likely only not work if the app was not built correctly from the start. However, that said, this is an interactive sim, not a typically accessible application. Providing some instructions that standard key presses work may provide assurance to some users. In my interviews, participants did think aloud phrases like this:

Will pressing the Escape key close the dialog?

And then they proceeded to press the Escape key and it worked as they had wondered out loud.

I think it is ok to add some explicit general things. They can choose not to read it, especially when the document is well organized and easily navigable. Some sims will have more complicated help than others.

An example from my early research on this was from a flickr app, their help dialog included a statement like,

Escape key closes dialogs, like this one.

Which could be nice at the very end, also under the "General operations" heading.

Regarding the title - just noticed that - I prefer "Hot keys and Help". One participant I interviewed early on where the cue just said "Press H key for Help" commented something like

I don't need help. I just need to know how it works.

I notice your ??? question marks. We are using the "H key" for "Hot keys and Help" in BASE for a few reasons:

• We don't have an accessible button to use.
• We can only use a key while in Application mode because screen reader hot keys use everything else.
• The H key does not require the shift key, whereas the question mark key does. This may require some more research.

Once there is a visual button in the sim header/footer, a Hot Key for help may not be necessary.

[arouinfar]

Thanks for the feedback @terracoda! I was using ??? as a placeholder, because @emily-phet's original post didn't specify the key for the help menu.

I think it is ok to add some key explicit things. They can choose not to read it, especially when the document is well organized and easily navigable. Some sims will have more complicated help than others.

Sounds good. I think for a sim like BASE, we'll want to have some top-level categories for sim-specific things, and more general navigation. If we go the more minimal route, I think everything can be listed together, like so:

[terracoda]

@arouinfar looking good. Just a couple of adjustments.

I would put periods at the end of each, so there are pauses at the end.

I should have said "Escape key closes a dialog, like this one."

And, to be consistent, I would refer to "this page" with the same language, so:

"H key opens this dialog." It's a dialog not a menu :-)

[arouinfar]

How about this @terracoda? If the verbiage and ordering looks good, I can start working on aesthetics.

[terracoda]

@arouinfar,

Shift plus Tab keys move to next item.

sounds a bit awkward. Sorry I didn't catch that before. I think,

Shift plus Tab moves to previous item.

sounds better.
Other than that, it's great!

[arouinfar]

Thanks @terracoda! I will start working on a few layout/color options

[emily-phet]

Looking great! @arouinfar I would suggest returning to earlier wording for the description of the arrow keys - "Left and Right arrow keys move the hand or the foot". I think "opposite directions" could be confusing.
I'm not sure about the use of "dialog". It's true that it is a dialog, but I doubt many people really know what that means - so likely it will just be ignored. Let's go with the use of "dialog" but keep an eye out for feedback that this is confusing to users. The addition of "like this one" helps. @terracoda's interviews were with people quite adept (in general) with their screen readers, which announce what type of element they're interacting with. Most users aren't exposed to that level of detail in their typical web interactions.

[arouinfar]

Thanks for the feedback @emily-phet! I will make the suggested changes to the descriptions, and work on a few mockups later this afternoon.

[terracoda]

@emily-phet, @arouinfar other possible words for "dialog" could be:

• modal (also a bit technical)
• pop-up
• pop-up box
• window
• pop-up window
• document (a bit dry)

Just words to keep in the coffers. And the addition of "like this one," would be god in all cases.

[arouinfar]

Thanks for these suggestions @terracoda. I think "pop-up" might be a good alternative to "dialog". I also like window, but I think it could get confused with the browser window.

The good news is that once the dialog is implemented, it'll be really easy to make changes to the text. :)

[jobara]

Maybe the same as the dialog, "Hot Keys and Help" or maybe just "Help"?

[jessegreenberg]

Thanks @jobara I went with "Hot Keys and Help" for now.

[terracoda]

@jessegreenberg, @jobara, sorry for the late comment on this and sorry for my question about using the close button as being a little vague.

What I was a little uneasy about after reading the article by Paul J. Adam was setting focus to a non-interactive element (i.e. the H1 of the dialog), which would be my first choce. This is why I suggested that we set focus to the only interactive element we have in this dialog, the close button. An interactive element was recommended by Paul J. Adam.

In a 2014 article in [Smashing Magazine] (https://www.smashingmagazine.com/2014/09/making-modal-windows-better-for-everyone/), Scott O'Hara seems to set focus to the containing frame, and then on entering the frame the first element that is read is the H1. On pressing tab the focus goes to the first focusable element within the dialog, a form element.

What I think we want for users in our case is:

1. to clearly understand that they have opened the keyboard help dialog, and that they are now in that dialog
2. to be able to use the arrow keys to read the content of the dialog at their own pace
3. to close the dialog intuitively by hitting escape or activating the close button
4. from the label of the original keyboard help button and from the heading of the dialog they should understand what the dialog is about

I see three options:

1. We stick with the current option of setting focus to the close button, and if so I think we should use the more explicit label for the close button, e.g. "Close Keyboard Help."
2. We set focus to the H1, a non-interactive element, if this is safe to do so. In this case, we can use the more simple content for the close button label, "Close".
3. Set focus to the dialog container and we should label the container with the H1 with aria-labeledby and set focus to the close button with the simple label, "Close".

My preference is actually option 2, but I was not sure, based on earlier discussion, if that was technically possible in our case.

[terracoda]

@jessegreenberg and @jobara, this ARIA Dialog Example from Athena ICT highlights (sorry, puts focus on) the H1 of the dialog. It works nicely in VO in Safari and in Chrome, BUT I can still navigate into the background page content without exiting the dialog...so the example is not a perfect one.

[terracoda]

@jessegreenberg, @mcking65 (Matt King) will be making a few dialog examples available soon. See the issue#103 over in ARIA-Practices 1.1 .

Matt King also commented:

For dialogs with lots of content that can scroll, it is good to have focus on an element in the portion that is visible when the dialog opens. That could be a heading if there are no interactive elements.

So based on this, I think we should go with option 2 in #127 (comment)

And the close button can now actually be placed after of the content. Visually it should still be up in the right hand corner of the dialog.

[terracoda]

@jessegreenberg, based on earlier discussion in issue issue phetsims/a11y-research#12 and yesterday's A11y Meeting (March 14), I think the label for the button that opens the keyboard information has changed from:

• Hotkeys and Help: Tips on how to use this sim with a keyboard.

TO

• Keyboard Shortcuts: Tips on how to use this sim with a keyboard.

Also in issue
phetsims/a11y-research#12 (comment) we discussed other content for the bottom bar.

@jessegreenberg, is the final version of the content clear? I think I should post a new summary over in phetsims/a11y-research#12. It looks like we summarized and then made another change.

[terracoda]

@jessegreenberg, here are the new dialog examples from the aria-practices group
http://w3c.github.io/aria-practices/examples/dialog-modal/dialog.html

The examples are still undergoing a review, but they contain awesome design advice as well as working examples.

The examples include dialogs with a small amount of content and a large amount of content.

[terracoda]

@jessegreenberg, fyi, while the examples in #127 (comment) are excellent, and have good design advice, they still have some focus management issues.

[jobara]

@jessegreenberg for the "Hot Keys and Help" dialog, if i open it with the keyboard and press one of the arrow keys. I cannot use the esc key to close the dialog.

Steps:

1. Use the keyboard to open the "Hot Keys and Help" dialog
2. press any of the arrow keys
3. press the esc key ( Notice that the dialog doesn't close ).

I tried this using Safari 10.0.3 on macOS 10.12.3

[jobara]

@jessegreenberg the esc key also exits out of full screen. This is not mentioned in the "Hot Keys and Help" dialog. Additionally this causes some interaction issues when interacting with dialogs while the sim is in full screen.

Steps:

1. Put the sim in full screen
2. Use the keyboard to open the "Hot Keys and Help" dialog
3. press the esc key ( Notice that the sim exits full screen, and focus is lost. You can no long exit the dialog with the keyboard )

[jessegreenberg]

Thanks @jobara!

• Design of Popup Dialogue for Keyboard Nav Help #127 (comment)

Unfortunately, I can't reproduce this issue with Safari 9.0.1, OSX 10.9.5.

• Design of Popup Dialogue for Keyboard Nav Help #127 (comment)

Good catch! @terracoda @emily-phet @arouinfar should there a description in the Keyboard Help dialog that describes escape will also exit full screen mode?

press the esc key ( Notice that the sim exits full screen, and focus is lost. You can no long exit the dialog with the keyboard )

I am using an older version of Safari and focus isn't lost when the sim exits full screen so I can still close the Dialog. But maybe the issue is that the dialog should get priority for closing over full screen mode.

[jessegreenberg]

It seems that for security reasons, you can't prevent exiting full screen when pressing 'escape'. So we need to figure out why focus is leaving the dialog when full screen mode is turned off.

[terracoda]

@jessegreenberg and @jobara, I am losing focus all together after exiting full screen mode. I can't seem to tab to anything after exiting full screen mode. Hmm, very strange.

@jessegreenberg can you actually tell where focus is going?

[jessegreenberg]

Probably the body - @jobara do you happen to know? I might be able to get a macOS device soon to check, but I am not sure.

[jessegreenberg]

We just tried this in Safari and Chrome in macOS Sierra 10.12.4 Beta, and we couldn't reproduce this bug. @jobara or @terracoda can we screen share sometime so I can observe this bug?

[phet-steele]

I did not experience the problems in #127 (comment) or #127 (comment) using Chrome with macOS 10.12.4 (NOT beta)

[jessegreenberg]

#127 (comment) I also just updated the machine to 10.12.4 (not beta) and could not reproduce the issue in Safari 10.1.

[jobara]

@jessegreenberg I just upgraded to macOS 10.12.4 which comes with Safari 10.1. It seems the issue is gone now. I tried before upgrading and the issue was there. It seems that this was a Safari bug, that has now been addressed.

[jessegreenberg]

Excellent, thanks very much @jobara. Is this still part still an issue?

@jessegreenberg for the "Hot Keys and Help" dialog, if i open it with the keyboard and press one of the arrow keys. I cannot use the esc key to close the dialog.

[jessegreenberg]

@emily-phet @terracoda @arouinfar is this part of @jobara's comment in #127 (comment) something that should be addressed?

the esc key also exits out of full screen. This is not mentioned in the "Hot Keys and Help" dialog.

[jobara]

@jessegreenberg regarding ( #127 (comment) ) this also seems to have been fixed with the latest version of Safari.

[emily-phet]

@jessegreenberg If you're asking if we should add to the Hot Keys and Help dialog something about esc exiting full screen mode, I don't think we need to do that.

[jessegreenberg]

#127 (comment)

Thanks @jobara, thats great.

#127 (comment)

Ok, great @emily-phet, thanks. In that case, can this issue be closed?

[emily-phet]

@jessegreenberg I think this issue can be closed. :)