Enable keyboard users to expand and collapse submenus also when the navigation is collapsed

Created on 8 March 2024, 9 months ago
Updated 12 April 2024, 8 months ago

Problem/Motivation

When the navigation is expanded a keyboard user is able to tab through all the top level menu items as long as a submenu is not manually expanded either by mouse or keyboard interaction (see expanded.mp4).
The behavior when the navigation is collapsed is different (see collapsed.mp4). With the mouse cursor the submenu is expanded on hover which is ok, the "problem" is when a keyboard user is interacting (tabbing) with the navigation. As soon as a top level menu gets into focus that has a submenu that submenu gets automatically visible and the focus moves to the submenu item. That way the keyboard user has to move through the entire top level of menu items as well as all the entire first level of sub menu items available. The user has to move actually through the entire first level menu and first level sub menu tree. If the user is moving backwards with "shift tab" the corresponding submenus are expanding but the focus remains on the top level menu items.

I've also added โœจ Tabbing order does not satisfy 508 accessibility requirements Needs review which is a related issue for the admin_toolbar, which also contains an extensive testing protocol for keyboard, screenreader and cursor to satisfy 508.

Steps to reproduce

  1. have the navigation expanded and tab through it, when the end of the navbar is reached "shift tab" back up
  2. collapse the navigation and now tab through it again, when the end of the collapsed navbar is reached "shift tab" back up

Proposed resolution

For the collapsed navigation don't open the submenu automatically on focus, no matter if you tab or shift tab through the menu. only expand the submenu to a top level menu item by pressing enter. that might also solve one problem of being able to visually distinguish if a top level menu item has a submenu or not when the navigation is collapsed, which would improve the situational awareness for everyone.

Remaining tasks

User interface changes

API changes

Data model changes

๐Ÿ“Œ Task
Status

Fixed

Version

1.0

Component

User interface

Created by

๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

Live updates comments and jobs are added and updated live.
  • Accessibility

    It affects the ability of people with disabilities or special needs (such as blindness or color-blindness) to use Drupal.

  • Usability

    Makes Drupal easier to use. Preferred over UX, D7UX, etc.

Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @rkoller
  • Assigned to silviu.serdaru
  • Pipeline finished with Success
    9 months ago
    Total: 149s
    #116794
  • ๐Ÿ‡ท๐Ÿ‡ดRomania silviu.serdaru

    Added a fix for this. Now, if the navbar is collapsed and you navigate with the keyboard, the submenus will open when you press ENTER. If you press ENTER again or if pressing Shift + Tab before focusing on the submenu, it will close.

  • Status changed to Needs review 9 months ago
  • First commit to issue fork.
  • Pipeline finished with Success
    9 months ago
    Total: 171s
    #117143
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia ahsannazir

    The keyboard navigation is now working fine. I just fixed some linting prettier errors. Attaching screen recording for reference

  • ๐Ÿ‡ฉ๐Ÿ‡ชGermany rkoller Nรผrnberg, Germany

    Thank you @Silviu S. for the initial patch! I've manually tested the latest state to the MR including the changes from @ehsann_95. A few observations and thoughts:

    The MR solves the problem of the tabbing order if the navigation is collapsed. You are now able to tab back and forth through the top level items as long as you don't expand one of the available sub menus by pressing the return button or spacebar.

    The only problem i see (probably out of the scope for this issue but might justify a follow up issue), at the moment there is no direct visual cue for sighted keyboard users if a menu item has a submenu or not. This detail is currently only communicated indirectly, menu items without a submenu show some sort of "tooltip" with a black background showing the name/label of the menu item. That is the same behavior as on hover, the only difference, for top level menu items with a submenu, that submenu is directly shown on hover, while the submenu has the name/label of the parent top level menu item on top.
    So it might be useful to have such sort of label in the form of the black tooltip for top level menu items that have a submenu but at the same time to provide some sort of visual cue that helps to directly identify top level menu items that have a submenu.

    And I wonder if it would make sense to add (at least for the collapsed navigation state but probably might make sense for the expanded state as well?) to add the option for the user that pressing the esc key closes an open submenu and the focus returns to the parent top level menu item?

  • ๐Ÿ‡ท๐Ÿ‡ดRomania silviu.serdaru

    @ahsannazir thank you for your update. Tested it and everything seems fine.

  • Status changed to RTBC 9 months ago
  • Status changed to Needs work 9 months ago
  • ๐Ÿ‡ท๐Ÿ‡ธSerbia finnsky

    @Silviu S. hello! thank you for work!

    One thing here. Could you please provide MR without formatting fix? only real changes. It seems impossible to review what was changed

  • First commit to issue fork.
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada SKAUGHT

    @finnsky @SilviuS
    yes #7 clearly says it was just formatting. i've reverted that commit.

  • Pipeline finished with Success
    9 months ago
    Total: 145s
    #117623
  • Status changed to RTBC 9 months ago
  • ๐Ÿ‡ท๐Ÿ‡ธSerbia finnsky

    Looks good to me.
    Moving back to RTBC. Thanks everyone!

  • Pipeline finished with Success
    9 months ago
    Total: 152s
    #118053
  • Status changed to Fixed 9 months ago
  • ๐Ÿ‡ช๐Ÿ‡ธSpain ckrina Barcelona

    Thanks all! Merged :)

    @rkoller noting all your ideas in #9. This week we're going to start implementing the new designs and hopefully we can implement them there: the interactions will change slightly, that's why I've merged this already so we iterate piece by piece.

  • Automatically closed - issue fixed for 2 weeks with no activity.

  • Issue was unassigned.
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada SKAUGHT
  • Pipeline finished with Success
    8 months ago
    Total: 53s
    #150236
  • Pipeline finished with Success
    8 months ago
    Total: 55s
    #150245
  • Pipeline finished with Success
    8 months ago
    Total: 51s
    #150246
  • Pipeline finished with Success
    8 months ago
    Total: 53s
    #153359
  • Pipeline finished with Success
    6 months ago
    Total: 316s
    #193578
  • Pipeline finished with Success
    6 months ago
    Total: 149s
    #193692
  • Pipeline finished with Success
    6 months ago
    Total: 151s
    #193704
  • Pipeline finished with Failed
    4 months ago
    Total: 428s
    #254946
  • Pipeline finished with Failed
    4 months ago
    #254952
Production build 0.71.5 2024