Non-standard keyboard behavior for user options submenu

[rhoadsstevens]

Priority level 1 (out of 3) from UW Accessible Technologies

WCAG mapping: 2.1.1 Keyboard

STEPS TO REPRODUCE:

1. Navigate to the User Options menu button
2. Press space to open the submenu

OBSERVED BEHAVIOR:
With Firefox, after opening the submenu, focus is not moved inside it. The submenu is not navigable using the arrow keys. Tabbing is required to move focus into the submenu and to navigate within the submenu.

Note that on Chrome instance, the submenu is navigatable with arrow keys, although there is a cursor that you can use to move between letters along with the current focus indicator. Additionally, there is a blank tab stop in between the "User profile" button and the submenu itself.

EXPECTED BEHAVIOR:
Upon presenting a submenu to users, they expect the standard behavior of being navigable with the arrow keys. Not meeting this expectation confuses keyboard users, and they are forced to discover how this specific submenu works. Additionally, the current implmentation adds another 4 tab stops that could be avoided if the submenu was arrow key navigable.

[tsmyre]

CIC Comment
Actions: - add arrow/home/end navigation per design pattern. As this is optional in the W3 pattern, we’re flagging this as low priority. - remove hidden close button

Washington Reply
This works for us.