Should keyboard navigation loop in the simulation?

[jessegreenberg]

From #116, @terracoda mentioned that

User kept getting stuck on the main "reset" button - no wrapping to top. Will look more closely at video. Not sure what is causing that.

I am not sure if it id desirable for the navigation to loop through the sim. This could be annoying to a user that is counting on 'tab' to leave the simulation area and get back to the browser interface.

@terracoda were users able to 'shift tab' to get away from the button?

[terracoda]

@jessegreenberg In instance 10, on the Surface Pro 3, the user actually got stuck on the Reset button. I am not sure why, but it happened a few times. When he got stuck, he was actually stuck. He couldn't go forward or backward. He hit TAB and he just heard "Reset" again and then if he hit Shift-TAB, he heard "Reset" again. To get unstuck, the user changed navigational strategies. In a couple of cases he switched to ARROW keys to get away from the Reset Button (and that worked) and in one other case he used the JAWS command "B" to go to the next Button. In that case, virtual focus wrapped to top and landed on the Yellow Balloon (which is a button in instance 10).

What I think should happen if the user TABs beyond (forward from) the Reset Button is that their focus should go to the browser because they are at the end of the Sim. This seemed like a problem in my first interview, but I think it seemed like a problem at the time for other reasons.

Eventually, tabbing past the Reset Button will take the user into the footer of the sim page or to the other Tab Navigation for the other sim pages on a multi-screen simulation.

[jessegreenberg]

Thank you for describing what happened! I will investigate this, see if I can reproduce on one of our platforms.

For your description of the way tab navigation should eventually behave, I completely agree. That makes sense to me, and that navigation would be the default for the browser. I don't think the user would encounter any surprises with that behavior.

[jessegreenberg]

One thing I noticed when testing with JAWS and IE is that the focus seems to get stuck around the 'Add wall' and 'Reset Balloon' button. Focus moves around to the correct HTML element, but description and keyboard event callback are stuck on one of these two buttons. It is as though the virtual cursor is getting out of sync with the HTML focus.

[jessegreenberg]

It looks like there is an issue with the structure of these inputs. These inputs have children, which is not valid HTML. Since none of the label text is visible, I think it should be acceptable to replace the paragraph descriptions with an aria-label.

Ideally, these buttons would be represented with something like:

<div id='button-container-id>
  <input type='button' value='Button Label' aria-describedby='description-id'>
  <p id='description-id>Button Description</p>
</div>

This is tricky with scenery because the node must be represented by the input element to receive the focus highlight correctly. The above structure is possible, but it requires some sim side complexity.

Currently, the button looks like this:

<input type="button" value="‪Reset Balloon‬" aria-describedby="reset-all-description-17-42-423-468-462-459">
  <p id="reset-all-description-17-42-423-468-462-459">‪Select to ‪Reset Balloon‬ to initial position and an uncharged state.‬</p>
</input>

But it could be represented with:

<input type="button" value="‪Reset Balloon‬" aria-label="‪Select to ‪Reset Balloon‬ to initial position and an uncharged state.">

This would simplify things significantly.

[jessegreenberg]

Another possibility could be the following, assuming role=button is handled correctly

<div id='button-container-id tabindex="0" aria-label="Button Value" aria-descrbedby='description-id' aria-role="button">
  <p id='description-id>Button Description</p>
</div>

This is my favorite. It allows us to nest labels and descriptions as desired, and the parent div receives focus. This is how rectangular push buttons should be represented.

[jessegreenberg]

One downside is that 'click' event is no longer handled by default. We need to handle onkeydown ourselves for keyboard support. The screen reader should let these go through. Input would become a dependency for RectangularPushButton.

[jessegreenberg]

It looks like 'click' is actually supported for many platforms with the button role:
http://unobfuscated.blogspot.com/2013/05/event-handlers-and-screen-readers.html

But it it not predictable, there is no common event across browsers for the button role. Firefox and OS devices do not support it. If the behavior is mimicked, NVDA requires that the user be in forms mode to even use the buttons. Even though it is recommended by the W3 (https://www.w3.org/TR/2015/WD-wai-aria-practices-1.1-20151119/examples/button/button.html#) Unobfuscated Blogspot source suggests that buttons NOT be represented with divs. I agree, and we are back to

<input type="button" value="‪Reset Balloon‬" aria-label="‪Select to ‪Reset Balloon‬ to initial position and an uncharged state.">

[jessegreenberg]

Button name is ignored by screen reader with this representation. No need for this to be an input, perhaps something like

<button aria-label="‪Select to ‪Reset Balloon‬ to initial position and an uncharged state.‬">Reset Balloon</button>

[jessegreenberg]

Again, the aria-label is not an additional label, it overrides the visible name.

[jessegreenberg]

What we really need is to to add a feature to the scenery API that allows us to create a structure like:

<div id='button-container-id>
  <input type='button' value='Button Label' aria-describedby='description-id'>
  <p id='description-id>Button Description</p>
</div>

The node itself is represented by the input, but it can exist in a container element that will hold descriptions, labels, or other content for the screen reader.

This has been required in several cases outside of this issue.

[jessegreenberg]

I will test the structure suggested in #121 (comment) in balloons-and-static-electricity to see if this solves issues with JAWS and getting stuck on input elements with children.

If it does, this structure should be supported by scenery.

[terracoda]

@jessegreenberg, I think we may still need an aria-label on the input element. You can think of labels as essential or required and descriptions as extra or optional. The html value attribute does not provide an accessible name in the Accessibility Tree. Every element needs an accessible name. There are generally 3 ways to provide an accessible name:

1. in content node of the element itself, <button>A11y Name Here</button>
2. in the content of another element associated via an aria-labelledby, or
3. in an aria-label attribute when the element does have text content elsewhere.

I'll be more active after Friday.

[jessegreenberg]

@terracoda I think you are correct, the label will be required. aria-label could work well, something like

<div id='button-container-id>
  <input type='button' aria-label='Button Label' aria-describedby='description-id'>
  <p id='description-id>Button Description</p>
</div>

would be fine. value attributes are also read by the screen reader as labels for button inputs, I have been following the accessible button examples from http://webaim.org/techniques/forms/controls#button.

I was hoping that we could streamline the DOM element into a single line (like #121 (comment)), which meant using both the content node for a label and an aria-label for a description. But it looks like the aria-label actually overrides the content node for the accessible name. In retrospect, it makes sense that an aria-label cannot be used for a description.

[jessegreenberg]

Revisiting this issue, can no longer get stuck on elements. I have not made any changes yet, I am not sure why I can no longer reproduce this issue.

[jessegreenberg]

Buttons now structured as described in #121 (comment), with the aria-label attribute. The input elements are contained under a parent div element so that the description can be added in addition to the button's accessible name.

Working great with NVDA in a few browsers, testiing JAWS next.

[jessegreenberg]

JAWS seems to work very will, tested in both IE and Firefox. Live regions working very well too 👍 Closing.

[terracoda]

@jessegreenberg, I see you tried a regular button tag. That should work as a single line DOM element if one doesn't need a description, right? Were there other issues with just using a button?

<button>Button Label</button> 

and this might also be possible when a description is not necessary

<button>
  <img src="path/to/image" alt="Button Label"/>
</button>

Sorry I am a bit late to the discussion.

[jessegreenberg]

That should work as a single line DOM element if one doesn't need a description, right?

Yes, that is correct. Right now the button is represented as a single line if no description is necessary, like

<input type='button' aria-label='Button Label' aria-describedby='description-id'>

and nested in a div if the description is necessary. As for whether to use an input element or a button, they seem to behave the same across screen readers. No values are submitted from button elements in the parallel DOM, so we don't have to worry about behavior differences between <button> and <input type='button'>. Do you have a preference for which one we use @terracoda?

[terracoda]

@jessegreenberg, the button element was created to replace input type="button". I do prefer the button element.

[jessegreenberg]

Sounds good @terracoda, I will change to use a native button. This change will need to be done in sun.

[jessegreenberg]

Done, all buttons (including toggles) use button instead of <input type='button'>. I believe this issue can now be closed.