This is a follow up issue from #2940023: [PP-1] Improve accessibility of Umami's responsive main menu

The button is outside the navigation landmark. When closed, a screen reader user might search for the navigation landmark region, but find it empty (a heading but no other content). They should find the button inside the nav landmark region.

proposed resolution

Move the button inside the nav element.

before

button
nav
    h2.visually-hidden
    ul.collapsed

after

nav
    h2.visually-hidden
    button
    ul.collapsed

Update CSS as necessary to maintain the design.

Comments

markconroy created an issue. See original summary.

andrewmacpherson’s picture

Priority: Normal » Major
Issue tags: +Accessibility, +Out of the Box Initiative

Thanks for filing the follow-up, this is one of the things I classed as a should-have in #2940023: [PP-1] Improve accessibility of Umami's responsive main menu.

Promotingi it to major, as this relates to two WCAG success criteria at level A - 1.3.1 Info and Relationships, and 2.4.1 Bypass Blocks. Specifically, it's about our implementation of technique ARIA11: Using ARIA landmarks to identify regions of a page.

Having said that, I don't think it needs to be a stable-blocker for OOTB - reasons follow....

Bypass Blocks is really about helping users to be able to skip past blocks, but this issue is about the button not being found inside the right landmark region when a user intentionally skips into the navigation region. The fact that we have landmark regions at all, and the menu defaults to collapsed at narrow breakpoints, and there's a skip-to-main-content link, means we have Bypass Blocks covered well.

It's more of an issue for the "Info and Relationships" criterion. An assistive tech user who jumps to the navigation landmark, at the narrow breakpoint, may not find the button to open the menu. Now this is mitigated in a few ways, so users don't necessarily face a brick-wall barrier in finding the button:

  • The button is visually clear, so sighted users can find it, whether they use a pointer device or speech control.
  • Sighted keyboard users with a browser plugin for landmarks might get frustrated, but visible focus styles can help them realize they need to tab backwards.
  • Visually-impaired users, using a screen reader's landmark tools are probably the group most strongly affected by this. The mobile nav region is initially empty. However the menu button is discoverable by tabbing though all controls, and several screen readers provide a "list all buttons" tool.
hiway’s picture

Please take a look at the path in this issue https://www.drupal.org/project/drupal/issues/2973257. I made some changes for the main menu button there. I kept the principals of the Inclusive components https://inclusive-components.design/menus-menu-buttons/ there, may be that will be a solution.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

andrewmacpherson’s picture

Issue summary: View changes
Status: Active » Postponed

This should wait until #2940023: [PP-1] Improve accessibility of Umami's responsive main menu is in. That's progressing well, and it's more important to get the JS behaviour stable first.

@hiway I took a look at patch #4 on the other issue. It doesn't address this issue - this is solely about what landmark region the button is placed in.

I've updated the issue summary, to show approximately what the DOM looks like before & after.

After using patch #46 from #2940023: [PP-1] Improve accessibility of Umami's responsive main menu,
I tried a quick edit of the block--umami-main-menu.html.twig template, just moving the button inside the Navy element, so it was between the H2 and the UL. I just wanted to see what would break.

It wasn't too bad. The JS/ARIA behaviour still worked. The button moved to the centre if the column, and down to just beneath the site logo.
So hopefully we can fix that with a CSS position.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

smustgrave’s picture

Not sure if Umami is being deprecated is this still valid?

mgifford’s picture