[PLAN] Accessibility review for new Navigation bar

We have automated Nightwatch a11y tests in core:
https://www.drupal.org/project/drupal/issues/3293469 📌 Automated A11y tests in Nightwatch Fixed

Added simple tests using it. For now 2 failures related to current 1.x Navigation:

   – Accessibility - Navigation Module - Claro page (3.125s)

   → ✖ NightwatchAssertError
   aXe rule: duplicate-id-aria - IDs used in ARIA and labels must be unique
        In element: aside

   – Accessibility - Navigation Module - HomePage with Umami (2.963s)

   → ✖ NightwatchAssertError
   aXe rule: duplicate-id-aria - IDs used in ARIA and labels must be unique
        In element: aside
   → ✖ NightwatchAssertError
   aXe rule: landmark-unique - Ensures landmarks are unique
        In element: #menu-builder

For tests:

1. Setup NightWatch as described:
https://git.drupalcode.org/project/drupal/-/blob/11.x/core/tests/README....

2. Clone Navigation module to /modules dir.

3. Run: yarn test:nightwatch --tag navigation

Later we need to add tests for:

- Tab navigation
- Collapsed state Tooltips/Menus

etc.

Hi @finnsky! Sorry If I wasn't clear the other day: this issue is not supposed to have any MR, just links to other issues with their own MR. Could you open 1 or 2 child issues yourself and add the MR in there?

Yep, This is only approach MR. I think it is cool to have nightwatch testing. Not even only for A11y

Un-postponing this after first iteration of mobile has made it so the plan definition can start from something more realistic..

Adding 🐛 Avoid duplicated IDs on the sidebar Active , also credited @finnsky in there for finding it.

@finnsky I've added ✨ Evaluate adding Nightwatch tests Active to move the discussion into its own issue. Could you add any missing information you think could help and move the MR to there?

Is there any way to add searching within menu tree?

There's old core issue about it #102254: Add an administrative search feature →

I'm adding my feedback from slack to hear opinions

Thanks @kostyashupenko, copying the answer from Slack so anybody landing here have context :)

tldr: in the first round of Usability tests 🌱 Toolbar Prototype Usability Testing Phase I Fixed we found that using a split button (initial approach, link+button) was confusing for users. Even with the initial designs showing that there were 2 things (link + submenu toggle), so we changed to the current approach for the second test 🌱 Toolbar Prototype Usability Testing Phase 2 Fixed with the University of Minnesota UX experts (with experienced Drupal users too). This approach proved to be the most usable, plus it’s a standard pattern (so what users expect).

The missing thing to solve is how to get to the parent pages. We have several solutions in mind (like adding that link on the submenu itself), but the main question is: are those admin list pages really necessary? The only extra thing they give is a description. If you can get to the links through the menu itself, the only page that could be argued that the only pages that really gives something is the Configuration page. We haven’t get to a perfect solution yet, so any idea is welcome.

But using a split button have proven to not be the most usable solution, so if we really want those pages (which don’t add any value apart from listing child items that you can see on the menu already) we need to find another way to do so :)

Sorry @andypost I totally missed your question before. We're not thinking about integrating it in the initial MVP/alpha, but we're planning on working with the Admin Toolbar maintainers to be sure their features integrate with this new toolbar and they have a solution for it.
Either way, we have designs for a search box and it would be great to have such a feature at some point integrated. Let's see where we can get :)

Adding more issues.

Adding related issue.

Adding 📌 Provide more helpful region labels Active as a child issue.

I've created an issue ( 📌 Improve the color contrast for structural interface components Active ) about the color contrast for structural interface components for Claro in general, but one of the examples (example C) covers the navigation module in particular. This kind of problem isn't covered by any WCAG success criterion at this point. Therefore I don't wanted to directly add the issue to the issue summary or link it as a child issue. Therefore I've decided to just leave a comment.

On the other hand I'll add 🐛 Icons are invisible in high contrast mode Active to the issue summary. I've already added it as a child issue a few days ago but forgot to comment in here and add it to the issue summary.

Created another issue in the context of keyboard interaction: 📌 Enable keyboard users to expand and collapse submenus also when the navigation is collapsed Active

I would like to have some nightwatch-axe Core tests set up to test the new navigation. I think that the dynamic functionality that we're going to want to be able to deliver should come with some dynamic automated tests.

Ideas on things that could be tested on the front-end (it'd miss tests for the admin pages):

• Collapse/expand the sidebar
• Scroll the sidebar (if the “content” is higher than the viewport height + footer)
• Open/Close the drawer on hover (submenu level 2)
  • Test it with edge cases, like moving fast to the top of the drawer - so the mouse leaves the targeted hover item
• Navigate to submenu level 3 (accordion)
• Navigate to User menu links
• See labels/tooltips of the 1st level links
• Active menu item on 1st, 2nd and 3rd level items
• (If logo) it takes you to the homepage
• Active item shows as so in the Toolbar

Attempt to follow @rkoller's suggestion on Slack and update the issue summary more as a plan with a protocol to follow. Probably a doc will need to be create a more completed protocol to follow.

Adding link to an environment to test.

The Tugboat environment in the current issue description is no longer available as of 4:49 pm PDT (+7) April 8, 2024.

Updated Tugboat link with a more reliable one: https://accessibility-tests-ibvgtgmk3akstqwvcqkak0ytg1ex70ce.tugboatqa.com/ and a few changes to the draft.

For the records, @charles-belov (Thanks to him for taking the time) tested the navigation module to validate if there are any concerns with animations in the context of vestibular disorder. His conclusion was: I'm not seeing any animation concerns in either mobile or desktop.

.

Added link to Google sheet with WCAG 2.2 success criteria for reporting issues.

I believe that the menu navigation as described in 📌 Ensure keyboard navigation works with the drawer Active is not behaving as described. The issue is marked as fixed. Would you prefer that I open a new issue or reopen 📌 Ensure keyboard navigation works with the drawer Active ?

Specifically, I can only navigate through the menu using tab and enter keys; the arrow keys don't accomplish anything. I actually prefer that. However, concerningly, escape does not work to exit sub-menus and I have to tab out of them. (I'm not filing this here in the current issue - I just wanted it here so that when you respond I can simply follow the desired instructions and not have to hunt this down somewhere else.)

Please advise.

@Charles Belov opening a new issue referencing the any previous work and whatever references needed is the ideal workflow.

@Charles Belov

You are right. Seems this tugboat instance is outdated.

Adding 🐛 Mobile version of Navigation should have focus trap Active

Updating test environment link with the latest changes now that Navigation is in core.

Updating title.

ckrina → changed the visibility of the branch 3391723-pp1plan-accessibility-review to hidden.

Opened 🐛 Buttons are not accessible with display: contents applied Active . Buttons are not accessible inside of display: contents;