[JAWS, IE11] Arrow keys do not move the focus highlight in the PhET Menu

[phet-steele]

To elaborate, if you use the arrow keys, JAWS still reads the description of the next item in the menu list even though the focus highlight does not change. "Enter" will select the item you heard the description of. So functionally, the menu behaves correctly, but visually the focus highlight is broken. Tab WILL move the focus highlight through the menu.

I was seeing this behaviour with JAWS on Win 10 + IE11.

For phetsims/tasks/issues/813.
URL: http://www.colorado.edu/physics/phet/dev/html/john-travoltage/1.3.0-dev.20/john-travoltage_en.html
Version: 1.3.0-dev.20 2017-04-05 17:45:45 UTC
Features missing: touch, fullscreen
Flags: pointerEnabled, msPointerEnabled, pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Tablet PC 2.0; rv:11.0) like Gecko
Language: en-US
Window: 1536x774
Pixel Ratio: 2.5/1
WebGL: WebGL 0.94
GLSL: WebGL GLSL ES 0.94
Vendor: Microsoft (Internet Explorer)
Vertex: attribs: 16 varying: 15 uniform: 512
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 16384x16384
OES_texture_float: true
Dependencies JSON: {"assert":{"sha":"a707328c","branch":"master"},"axon":{"sha":"f7beced2","branch":"master"},"babel":{"sha":"349f2b73","branch":"master"},"brand":{"sha":"054ca5c3","branch":"master"},"chipper":{"sha":"7c6e001f","branch":"master"},"dot":{"sha":"569939e1","branch":"master"},"john-travoltage":{"sha":"d3c5efa2","branch":"master"},"joist":{"sha":"d11d93da","branch":"master"},"kite":{"sha":"81166ce9","branch":"master"},"phet-core":{"sha":"c5c6c2a8","branch":"master"},"phetcommon":{"sha":"85801e7b","branch":"master"},"query-string-machine":{"sha":"d8a4ff18","branch":"master"},"scenery":{"sha":"e5fadaaf","branch":"master"},"scenery-phet":{"sha":"2cc12884","branch":"master"},"sherpa":{"sha":"ad343771","branch":"master"},"sun":{"sha":"cf75fc6d","branch":"master"},"tandem":{"sha":"cc7876d0","branch":"master"},"vibe":{"sha":"549baf54","branch":"master"}}

[jessegreenberg]

Thanks @phet-steele. My guess is that JAWS is intercepting the arrow keys and focusing the next list item instead of the next button, and then delegating the click event to the list item child? If focus is actually on the list item, scenery wouldn't know to place focus on the next button in the list. But I need to investigate.

[jessegreenberg]

Hmm, apparently that isn't the problem. When I delete the list items, so teh menu is just links and buttons, the problem is still there.

[jessegreenberg]

I will be comparing against this example: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-1/menu-button-1.html

Which does not exhibit the problem.

[jessegreenberg]

Accessible name for the menuitem widget comes from child text content of the li element.

Our LI's have child buttons and links, which are receiving focus. Is that the issue?

[jessegreenberg]

When I make the list items focusable (instead of the child items) JAWS handles focus correctly. We can change Scenery/AccessiblePeer to handle focus such the focus style is correct when parent container elements receive focus.

[jessegreenberg]

Works, but JAWS does not read any of the label content for the links in the menu.

[jessegreenberg]

Ah, figured it out - the none role is critical for the list items in the menu in order for JAWS to manage focus correctly.

That is absolutely ridiculous.

[jessegreenberg]

Example here: https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-2/menu-button-2.html#

Explanation from the W3C:

Hides li element native role semantics of listiem from assistive technologies.
If native role semantics of the li element are not removed, it could confuse some users of assistive technologies since listitems and menuitems would be interspersed with each other.

[jessegreenberg]

Focus in the menu is working great with JAWS after the above commits. Closing.