Customizer Menus: Accessibility: reordering menu items should have some indication about the item level

[designsimply]

/hat tip @afercia for the original report at ​https://github.com/voldemortensen/menu-customizer/issues/105

Splitting this out from the users test post on Make WordPress Accessible:
​https://make.wordpress.org/accessibility/2015/06/12/accessibility-usertest-menu-customizer/

When reordering menu items, there should be an audible indication of their level.

NVDA
When reordering menu items, NVDA announces “menu is now a submenu item” or “menu item moved out of submenu”, which is useful, However, when reviewing the list while reordering, there is no indication at what level any given menu item is currently set to.

Supernova
When using the reorder feature, there is no screen reader feedback to indicate the menus level, perhaps a level indicator can be added after the page title that says something like “top”, “level 1″, “level 2″, etc to show how far down the tree each menu item is. As this is only really to benefit screen reader users, it could be visually hidden using the CSS clip method.

[afercia]

In nav-menus.php they have (at least) some text to indicate they're sub-items. This could be further improved adding a depth indicator.

[afercia]

Changing from "enhancement" to "bug" as agreed with @obenland.

[celloexpressions]

Is the depth useful or would it be better to know what the parent item is? "Sub item under [title]"

[afercia]

Replying to celloexpressions:

Is the depth useful or would it be better to know what the parent item is? "Sub item under [title]"

I'd say no parent info but would be useful to know the actual sub items level.

[valendesigns]

Anymore suggestions/expectations on the output before I get started on a patch?

[afercia]

Just discovered something I was not aware of because, well it's pretty undiscoverable :) In the current nav-menus.php screen, menu items have some infos about the menu item level and parent. It's done with JavaScript as hidden text and also title attribute. I'd remove the title attribute and keep just the hidden text but the question here is: would users expect to find the same kind of information in the Menu Customizer too? See screenshot:

[celloexpressions]

@afercia could you advise on the ideal wording/information provided and where it should be placed (I'm guessing inside the edit menu item button like on the admin screen?)?

[afercia]

@celloexpressions I'd say it should be placed on the focusable elements, i.e. the buttons yeah. Something like what was done in 33151 for the available menu items, hiding redundant text with aria-hidden.
Not sure about the wording. Maybe use the same wording/information used in the admin screen to keep consistency? And then change it in both places if we find something better in future iterations?

[obenland]

No patch and we're a ew days away from beta4, let's iterate on this in a future release.

[celloexpressions]

There is clear direction above on the preferred text and location from the accessibility team. Re-typing as a bug because the experience is broken for some users and is worse in the customizer than in the equivalent wp-admin screen.

The next step is to create a patch. The patch will likely need to edit the customize menu item control's HTML template in addition to the JS methods that handle reordering and changing depth to keep the text updated when items are moved around.

[kushang78]

Added patch for this ticket.

[kushang78]

• As per above all threads & discussions, I've made some changes in below 4 files.

src/js/_enqueues/lib/nav-menu.js
src/js/_enqueues/wp/customize/nav-menus.js
src/wp-admin/includes/class-walker-nav-menu-edit.php
src/wp-includes/customize/class-wp-customize-nav-menu-item-control.php

The changes:

• Added sub-items text to customizer menu as same as nav-menus.php page.
• Added new title attribute for quick preview on hover for both.
• Show & Hide sub-items text with available, Drag & drop functionality and Reorder button functionality.

[joedolson]

Adding title attributes is something that we specifically avoid doing in WordPress, because they can cause a wide variety of accessibility problems. But I'll take a look at this soon.

[audrasjb]

As per today's bugscrub: @joedolson is it still in your radar?
It would be nice for this to be reviewed by next week. Or we can of course also put this ticket in milestone 6.6 to give it more time for review/discussion.

[joedolson]

This updated patch simplifies the changes. The original patch by @kushang78 included a few changes that I don't think we should make. First, the introduction of duplicate accessible name via the title attribute. Second, it modified the button text in the Customizer to match the format in the admin nav menus, but without also adding the equivalent JS to modify the texts as they are in the admin nav menus.

Overall, I think that the control's accessible name is currently better in the customizer than it is in the admin nav menus, so I don't think this should be changed in the customizer.

The Customizer accessible name format is "Edit menu item: {item title} ({item type})".

The admin accessible name format is "{item title} Menu item n of n". It doesn't include the purpose of the control or the type, so the Customizer is providing better information; the admin menu needs to be updated.

The patch doesn't address the idea of adding the menu item's depth in any way, and I think that's a more major thing to address.

I propose committing the version of the code in the simplified patch, which meets the intention expressed in the original ticket, and open an enhancement ticket to add depth to both menu interfaces and a bug to address the accessible naming in the admin menu interface.

While working on this, I also noticed an unrelated bug where the button text only would return either data.title or wp.customize.Menus.data.l10n.untitled, and didn't return data.original_title, which caused it to be untitled for any item without an explicitly defined title. It seemed reasonable to fix that at the same time.

[joedolson]

Simplified patch

[rcreators]

The patch is missing slash before src directory. so was not able to apply. I updated it and its working now. any one can test it. Patch works fine.

[rcreators]

Patch Test Result.

[swissspidy]

@joedolson Just checking in here as RC 1 is approaching soon, so I'd suggest making a decision on committing the patch if you feel it's ready, or else consider punting.

[joedolson]

Will commit tomorrow.

Trac ticket: https://core.trac.wordpress.org/ticket/32728

[joedolson]

In 57746:

Customize: Accessibility: Label menu subitems when updating menus.

Fix missing subitem indicator when menu items in the Customizer are children of parent menu items & add menu item original title to button text. Adds parity with the admin menu editor and fixes a bug where the button text was 'untitled' if the menu item title had not been edited.

Props designsimply, afercia, celloexpressions, kushang78, joedolson, rcreators.
Fixes #32728.

In r57746