Defect 3 - Critical - Menu Systems

[srancour]

Description or Additional Context

9/16/2024: The menu systems are not individually navigable with the keyboard. For each menu option the user must Navigate through each sub menu, sub sub menu and sub sub sub menu option before moving to the next open. The arrow keys do not work in the menu.

Example

On every page when you tab through the navigation, it forces you to go through every single menu and submenu, which adds in a ton of extra tab stops that are unnecessary.

Code snippet

Content menu

<li class="menu-item menu-item--expanded menu-level-0">
  <a href="/admin/content" class="toolbar-icon toolbar-icon-system-admin-content is-active" data-drupal-link-system-path="admin/content" aria-current="page">Content</a>
  <ul class="toolbar-menu lower-level-nav menu-level-1">
    ...
  </ul>
</li>

Steps to reproduce

Navigation: Home or any other page
Load page and tab through all navigation elements to see that you have to tab through every element that exists.

Recommended resolution

Ideally, there would be some combination of arrow keys that would allow you to navigate the menu options at each level, without needing to go through all the sub menu options.

This was captured already in #17764.

This issue seems to be coming from the Admin toolbar module.

Defect Criterion

WCAG 1.3.1 - Information and Relationships - Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.

Users affected

• Keyboard only
• Screen reader

Teams that this affects:

• CMS Team

[anantais]

Just wanted to update this ticket. @srancour - I have a fix for this that appears to work well but it is failing a cypress test. Hopefully I can get it fixed soon.

[anantais]

Reposting Steve's QA findings from the PR here:

So some interesting issues I found while testing that PR:

• When collapsing the screen down to where the menu reflows onto two lines the dropdown button still shows over the menu that’s open
  • 
• The button is changing names on press instead of doing like the Sections dropdowns do where the name of the button stays the same and the button uses the aria-expanded attribute. I would suggest changing the name to be {nameOfMenu} sub menu
  • Menu button code
    • closed: Extend Tools
    • open: Collapse Tools
  • Sections button code
    • closed:
    • open:
• On mouse hover the button isn’t switching or firing the open state so it doesn’t look open and a screen reader user won’t get the knowledge that it’s open.
  • 
• In the open state, there is no way to cancel the close after pressing on it with a mouse, where there is a way to cancel it when it’s closed, thus breaking WCAG 2.5.2: Pointer Cancellation (Level A)
  • Video showing mouse not being able to cancel by holding and moving off button
• When a menu gets opened up from a press, it doesn’t close when any of the parent menus closes. It’s not particularly an accessibility issue, but it makes for a bad experience.
  • Video showing menus not closing when parent is closed
• Interesting bug I discovered is when you are tabbing through, if you have the mouse hovering over a menu, it will tab through what’s visible, which is as it should be, but if you move the hover off the menu and then tab again, it throws the tab to the top of the page, which is really bad.
  • Video showing tab state moving to the top of the page after moving mouse off menu that was being tabbed through
• The color contrast of the dropdown arrow when focused doesn’t meet color contrast just barely (2.9:1 instead of 3:1)

[anantais]

This is the patch that I applied that Steve is referencing in the above QA:
https://www.drupal.org/files/issues/2024-11-05/admin_toolbar-3286466-keyboard-navigation-rerolled-3-5.patch

The patch is part of this issue which has to do with tabbing issues on the editor menus: https://www.drupal.org/project/admin_toolbar/issues/3286466
It looks like this thread has been monitored by the maintainers of the admin_toolbar module. This seems to be the main thread where people work on the tabbing issue itself which could be put into the module when it has reached a good state.

There seem to be a lot of issues and potential patches at this point but no large scale fix. I am documenting what I have found so far on this issue here:

This is original issue tracing back to 2019, with other issues linked to it - https://www.drupal.org/project/drupal/issues/3084529

This issue thread is referenced for Claro, which is the theme our backend is currently based off of: https://www.drupal.org/project/drupal/issues/3270230

[anantais]

My current recommendation, after looking through a lot of issue threads, is to table this for the moment. At the very least, I think it would be better to work through the other accessibility issues first. This has been getting worked on by other Drupal devs for years but it it obviously a pretty huge lift. I am hoping to see more active dev work on this since a patch was just rerolled earlier this month. I will commit to checking back in on this issue each sprint to see how it is progressing.

I would like to keep this ticket in the queue in some capacity so it is easy to revisit the relevant issue queues.

@srancour

[gracekretschmer-metrostar]

After talking to Amanda, Erika and I decided to pause this work, since there should be a fix coming down the pipeline from Drupal Core.