Components: Need keyboard navigation order to match visual order of menu items

Created on 4 Jun 2018  路  9Comments  路  Source: angular/components

Bug, feature request, or proposal:

I need keyboard navigation order of dynamic menu items to match the visual order in which the items appear.

What is the expected behavior?

In the stackblitz example below, I expect the down arrow key to navigate in the order A-B-C-D-E.

What is the current behavior?

The navigation order is A-B-D-E-C.

What are the steps to reproduce?

https://angular-material2-issue-gxemkt.stackblitz.io

What is the use-case or motivation for changing an existing behavior?

We're trying to use mat-menu for a dynamically created menu and the last menu item, "Sign Out", is being highlighted first -- something we definitely don't want to appear as a default menu action. We anticipate that this won't be the only issue we'll run into if we keep going with mat-menu, as the stackblitz demo above shows. There appears to be no way we can take control of the navigation order to fix this problem.

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

Angular 6.0.2, Material 6.0.2, Windows 7, TypeScript 2.7.2, Chrome, Firefox, and IE.

Is there anything else we should know?

P2 a11y has pr

Most helpful comment

Since I haven't seen anyone mention a workaround, the workaround I've been using is to put *ngIf="true" on every menu item that isn't otherwise conditional.

All 9 comments

I think this issue should be prioritized higher. All it takes is a single ngIf within a menu and the keyboard navigation order will be messed up. This is a pretty common pattern to hide or show menu options.

Anecdotally, the product I'm working on had more than one menu where the keyboard navigation order was messed up due to this bug. I am sure this is affecting the keyboard accessibility of a large number of Angular material apps.

*ngFor also influences the keyboard order https://stackblitz.com/edit/angular-7kfy5f-zt4wny?file=app/menu-overview-example.html

Is there something that can be done about the PR? Can I do something to make it happen faster?

We are using a very ugly workaround in order to make this work, so it would be cool to have it work out of the box.

It's blocked because there's a project inside Google that the fix breaks, and it's somewhat tricky to change their app to not break with the fix applied.

Ok, thanks for the information! Is there an estimated time of arrival?

Since I haven't seen anyone mention a workaround, the workaround I've been using is to put *ngIf="true" on every menu item that isn't otherwise conditional.

@DanielHabenicht most of the team is temporarily redirected to work on ivy, so it might not be until ~Q3 this year

@calebegg Thanks for the way easier workaround! It also works for *ngFor

@jelbourn Thanks for the information, that lets us plan ahead.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings

Related issues

AlanCrevon picture AlanCrevon  路  107Comments

kara picture kara  路  94Comments

julianobrasil picture julianobrasil  路  78Comments

tyler2cr picture tyler2cr  路  57Comments

mmalerba picture mmalerba  路  77Comments