Improve keyboard navigation

[callumbwhyte]

Now V2 / V3 is out, it would be awesome to improve the ability to navigate / tab around the Meganav in the backoffice with a keyboard. This will significantly improve both the accessibility and usability of the package.

Umbraco has come a long way with this in recent years and so most of the components being used work pretty well, just could be even better.

I can imagine there's several places where the tab index is off or triggers the wrong thing.

I'd love to see keyboard shortcuts for:

• Opening settings
• Adding a new item
• Toggling collapsed / expanded state
• Toggling visible state
• Reducing / decreasing menu level / indent

Marking this as "help wanted" to see if any helpful people out there want to have a go 😎

[eden-jh]

I tested this with a keyboard and poked around in inspector. I can confirm that there's currently no way to reorder items with the keyboard, but the controls use <button> elements so other functionality is either already keyboard accessible or has more easily-fixable issues:

• Adding a new item (at the bottom of the menu): Already keyboard accessible, no other issues
• Add a new item in between existing items: Missing an accessible name, but it's keyboard accessible
• Toggling collapsed/expanded state: Works with a keyboard, but the button should have an aria-expanded attribute that gets toggled to match the current state, so that screen reader users can tell when it's open (also, it will inform screen reader users that the button can expand without having to include "Toggle" in the accessible name)
• Toggle collapsed, toggle visibility, edit, and delete buttons should include the name of the menu item they apply to in the button text/accessible name, so screen reader users can clearly tell which button goes to which item
• Buttons have title attributes that are redundant to their accessible name, which will cause some screen readers to read it twice
• Toggle visibility, edit, and delete buttons must be visible on focus. Currently they are only visible on hover, so while they can be focused and activated with a keyboard, a non-screen reader keyboard user won't be able to tell where the focus is. Other than that they're already keyboard accessible
• Focus management works well for the most part (when opening an edit or add dialog, focus is moved to the first focusable element in the dialog, and when closing it, focus moves back to the control that was previously clicked) though it's worth testing this again once the controls are visible on focus. The only issue I noticed is that after creating a new item, when the dialog closes the focus moves back to the add button, not to the newly created item. (If they hit esc or cancel the item without adding it, focus should be moved back to the add button; it just shouldn't go there if they did create a new item)

When you say keyboard shortcuts, do you mean something like a hotkey to a specific functionality (like using letter keys with a modifier key)? If so, that's probably unnecessary for accessibility. (Some combination of tab/shift+tab, space/enter, and arrow keys should be sufficient.)

[eden-jh]

Oh, I forgot one thing. If I recall correctly, the visibility toggle needs a state so screen reader users will know whether it's active or not. aria-pressed is probably fine.

[callumbwhyte]

Thank you so much @eden-jh, this is very thorough! Looks like we have some easily actionable items which is great.

I’ve taken a look at the item actions being visible on focus, I believe we already have most of the styles required for this we’re just missing a tabindex on the outer nav item and the actions itself as they’re not inputs.

As for my initial comment about keyboard shortcuts, this wasn’t so much with accessibility in mind but for improving speed for power users. I think being able to add, edit, toggle collapsed / visible, for nav items with a hot key would be cool. Additionally indenting items via a hotkey. I’m not sure what best practice would be here, so as not to interfere with other browser functions or accessibility tools. I’m guessing Alt+something, and perhaps only when a specific item is in focus. Would love your ideas here.

Thanks again!

[eden-jh]

Ah, okay. Yeah, per WCAG 2.4.1 (Character Key Shortcuts) as long as there's a non-character modifier key included, shortcuts should not interfere with assistive technology.

As far as basic keyboard functionality for moving items, I did some research on accessible patterns for reordering, and I see two main implementations that could be useful here:

1. Each menu item contains a toggle button that when pressed, allows reordering via arrow keys (once you've moved it where you want it, you press it again to turn the dragging/reordering off)
2. Each menu item has a collapsible list of options for where it should be moved (up, down, inside of or outside of a specific parent item)

A version of approach 2 that requires you to re-open the menu after every move so you can choose "Move Up" a million times is not super usable, and I'm not sure it makes sense to keep the menu open as it's moved. Maybe including both approaches would be the most usable? A user can use the "Move into Submenu X" option to get a menu item into the right submenu, and then use the arrow keys to get it into the right position.

Some additional concerns for screen readers:

• Making sure screen reader users have information about the state of the editor (for example, aria-grabbed apparently exists but I'm not sure how well it's supported), and the results of their actions (e.g. when they successfully move an item)
• I know some screen readers don't present content as a list if it's set to list-style: none so it'll be important to test and make sure that hierarchical relationships are conveyed to screen reader users.
• One complication with approach 1: As was pointed out in schne324/dragon-drop#41, if a screen reader is in browse/virtual mode, most keypresses will be handled by the screen reader and not passed to the browser (so moving an item with arrow keys won't work for screen reader users if the screen reader is in browse mode). It has to be in Forms/Focus/Applications mode for those keypresses to be passed to the browser, which means there needs to be some kind of widget role

Here are some examples. Just as a note, there are two examples of approach 1 here that don't have the interaction mode issue, but they both use a listbox role which is not appropriate for the nav editor:

• WhatSock ARIA Drag and Drop: Examples of approach 2
• Dragon Drop: Approach 1, easier to predict where items will move than the Whatsock Listbox, but not usable for screen reader users because of the interaction mode issue
• Salesforce sortable listbox: Approach 1, works with a screen reader because it uses a listbox which puts it into Forms mode
• Salesforce sortable list: Approach 1, has the interaction mode issue
• Salesforce move between lists: approach 2
• WhatSock Aria Listbox (sortable): This one gets the screen reader interaction mode right since it uses a listbox. When you arrow through to move the item, the focus moves, but the item itself doesn't move until you press spacebar to accept it. While I appreciate that this lets you hit esc to cancel instead of moving it, I found I couldn't always reliably predict where the item was going to move.