Editing menus in WP admin for blind people

[juliemoynat]

Hi,

I've first created this ticket in WordPress accessibility support (​https://wordpress.org/support/topic/editing-menus-in-wp-admin-for-blind-people/) but this is not a support ticket so I re-post it here.

With a blind person, we noticed that navigate through the page to create menus with a keyboard and a screen reader is not easy. Then, I tried to help him by giving him a page description.

We noticed that :

• this page lacks titles at the top of blocks to explain what these blocks are. This would help blind people to better find each block and to navigate easily from one block to another.
• there are some masked explanations but not everywhere so, for example, he can’t imagine that clicking on links in “Menu structure” would have opened an accordion
• there are some tabs navigation (at the top: “Edit menus” and “Manage locations”, in the left column: “Most recent”, “View all”, “Search”) but blind people can’t know which one is active not either that they are tabs.

So, I think there are 2 steps to enhance editing menus in WP admin :

1. giving more informations by screen reader texts
2. using ARIA design patterns for tabs and accordions: ​https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex

For step 1, we could :

• for all tabs: add a screen reader text on the active one “(current tab)”
• for tabs at the top (“Edit menus” and “Manage locations”): remove the “h2” tag and use an unordered list (“ul”) with an “aria-label” attribute that would tell “Main tabs for editing menus”
• add a title before each block: for left column, this could be “Choose which links you want to have in your menu”, for right column, this could be “Change parameters for the links you added in your menu (order, label, title…)”
• add a screen reader text to “Add to menu” button, like “(after that, don’t forget to active “Save menu” button)”
• add a screen reader text to links in the right column (just like in the left one): “Press return or enter to open this section”
• add a screen reader text after the 2 first tabs, in a paragraph that would tell users something like “don’t forget to active “Save menu” button to save all your modifications”. So, if they don’t find that button, they could search it with their screen reader thanks to its name.

These texts would help blind people to navigate title by title and to understand how it works.

What do you think about it? Could it be added to WordPress admin?

[afercia]

Hello @juliemoynat and thanks for your ticket. I'd definitely agree this screen needs improvements. Unfortunately, the menus screen, together with the widgets one (see #40677), the media views, and the customizer, are the most critical areas in WordPress for accessibility.

Your suggestions make perfectly sense, I really hope there will be the chance to implement at least some of them in the next future. Regarding the tabs, an ARIA tabbed interface would probably be the best option. Accordions could benefit from some ARIA patterns. These are solutions that require a bit of time to be implemented, and a big refactoring of this screen. The main issue would still be the drag and drop functionality, that should be really replaced by something simpler and more accessible.

[juliemoynat]

Hi @afercia
Thank you for your reply. I know that using ARIA needs time to implement it. That's why I suggest first to implement some screen reader texts to help users without doing a lot of refactoring.
Blind people can't use this screen properly and this is one of the most important screen when you're doing a website. This is quite a blocking situation. Don't you think?

[afercia]

I'd definitely agree this screen needs improvements.

@juliemoynat I agree :) Noting that the accessibility team meetings are on Mondays at 17:00 UTC in the Slack #accessibility channel and any new contributor is very welcome!

[afercia]

Moving to future release as something that should be addressed, as per today's bug scrub. Some of the suggestions here would be very simple and there are no reasons why they shouldn't be implemented :) Note: the "tabs" would need a true ARIA treatment.

[audrasjb]

Related: #43305

[audrasjb]

For tabs at the top (“Edit menus” and “Manage locations”): remove the “h2” tag and use an unordered list (“ul”) with an “aria-label” attribute that would tell “Main tabs for editing menus”

[audrasjb]

Diff 1 + Add screen-reader-text hints to each column of the Edit Menus tab

[audrasjb]

Diff 2 + Add screen-reader-text hints to Add to menu buttons in menu item bar

[audrasjb]

Diff 3 + Add screen-reader-text-hints to Menu Items togglebar in the right sidebar

[audrasjb]

Diff 4 + Add screen-reader-text hints to the top of Edit Menus tab

[audrasjb]

Hi @juliemoynat @afercia

I worked on the first step on this big ticket :)

So, here are all the things I patched:

• for tabs at the top (“Edit menus” and “Manage locations”): remove the “h2” tag and use an unordered list (“ul”) with an “aria-label” attribute that would tell “Main tabs for editing menus”
• add a title before each block: for left column, this could be “Choose which links you want to have in your menu”, for right column, this could be “Change parameters for the links you added in your menu (order, label, title…)”
• add a screen reader text to “Add to menu” button, like “(after that, don’t forget to active “Save menu” button)”
• add a screen reader text to links in the right column (just like in the left one): “Press return or enter to open this section”
• add a screen reader text after the 2 first tabs, in a paragraph that would tell users something like “don’t forget to active “Save menu” button to save all your modifications”. So, if they don’t find that button, they could search it with their screen reader thanks to its name.

I didn't succeed to fix this one since it's dependant to a JS file which is used on several places. Caution: may be a breaking change.
-> for all tabs: add a screen reader text on the active one “(current tab)”

Feel free to ask for changes/fixes – but I know you will ;)

Cheers,
Jb

[juliemoynat]

Hi @audrasjb

Thank you for all you're doing!

I've read your "diff" and here are my observations:

• add a title before each block: I thought more of adding a "h2" tag (instead of a "span") because people can navigate through titles with their screen readers. I know that sighted persons who use screen readers don't like to have hidden titles but that can be a real help for blind persons, in my opinion.
• add a screen reader text to “Add to menu” button: good job. You find the right words ;-)
• add a screen reader text to links in the right column (just like in the left one): the text added is not at the right place (in the diff, it is in a "div" that can not receive focus). For this text being readable, we should add it in the link that have "item-edit" class. But... now, I see that this link has an aria-label attribute. (For information, an "aria-label" text overrides the content inside tags in a screen reader.) This attribute is suddenly modified with JavaScript... So this is more a bug to fix in JS.
  • Before JS:

    <a class="item-edit" id="edit-140" href="/wp-admin/nav-menus.php?edit-menu-item=140#menu-item-settings-140" aria-label="Edit menu item"><span class="screen-reader-text">Edit</span></a>
    

  • After JS:

    <a class="item-edit" id="edit-140" href="/wp-admin/nav-menus.php?edit-menu-item=140#menu-item-settings-140" aria-label="Mentions légales. Menu item 2 of 3."><span class="screen-reader-text">Edit</span></a>
    

  • What we should have: The script should add its text to the first one instead of override it: that's the only way to have a relevant link for screen reader users.

    <a class="item-edit" id="edit-140" href="/wp-admin/nav-menus.php?edit-menu-item=140#menu-item-settings-140" aria-label="Mentions légales. Menu item 2 of 3. - Edit menu item"><span class="screen-reader-text">Mentions légales. Menu item 2 of 3. - Edit menu item</span></a>
    

• add a screen reader text after the 2 first tabs: I'm looking for the "add-edit-menu-action" class in my browser web developer tool to see where the text is added but I can't find it. Is the text adding to the right place? I think this text could be placed just before the "div.manage-menus" element in a "p" tag (because it's a paragraph ;-) ).

I hope my comment is enough clear. Don't hesitate to contact me if you have any question :)

Cheers,
Julie

[audrasjb]

Replace span with h2 tag in screen-reader-text hint for both columns

[audrasjb]

add a screen reader text after the 2 first tabs: move this hint before div.manage-menus and transform it into a paragraph

[audrasjb]

Thanks @juliemoynat !

• add a title before each block: I thought more of adding a "h2" tag (instead of a "span") because people can navigate through titles with their screen readers. I know that sighted persons who use screen readers don't like to have hidden titles but that can be a real help for blind persons, in my opinion.

Fixed in 40678.7.diff

• add a screen reader text to “Add to menu” button: good job. You find the right words ;-)

Great ;)

• add a screen reader text to links in the right column (just like in the left one): the text added is not at the right place (in the diff, it is in a "div" that can not receive focus). For this text being readable, we should add it in the link that have "item-edit" class. But... now, I see that this link has an aria-label attribute. (For information, an "aria-label" text overrides the content inside tags in a screen reader.) This attribute is suddenly modified with JavaScript... So this is more a bug to fix in JS.

This one is quite tricky to implement. I'm still working on it.

• add a screen reader text after the 2 first tabs: I'm looking for the "add-edit-menu-action" class in my browser web developer tool to see where the text is added but I can't find it. Is the text adding to the right place? I think this text could be placed just before the "div.manage-menus" element in a "p" tag (because it's a paragraph ;-) ).

Fixed in 40678.7.diff

@afercia Theorical question: what is the process for partial fixes? Is it okay to commit some fixes but let the ticket open?

Cheers,
Jb

[audrasjb]

Ok, so I messed up while generating 40678.7.diff … this is a mix of several patches I made o others ticket :((((
I have to clean my local repo before sending a new patch.

[afercia]

@audrasjb @juliemoynat thanks for working on this :)

what is the process for partial fixes? Is it okay to commit some fixes but let the ticket open?

One thing I've learned contributing to WordPress is that it's better to keep patches small :) Trying to solve everything in one patch can sometimes make things harder. I'd suggest to keep things simple and split remaining issues in separate tickets.

A few suggestions:

• I wouldn't touch the accordions, there's already a ticket for that: #42002
• I know the wording Press return or enter to open this section is already used in core so it seems natural to reuse it, however it's not that ideal. Only a few keyboard layouts have different Enter and Return keys, and in any case it's a bit redundant. Users just need to know they have to activate the control. Also, I'd use aria-expanded when possible.
• “Edit menus” and “Manage locations” are not real tabs: they look like tabs but actually they're just links. It's more a sub-navigation menu and it should be marked up as such. However, there are other places in core where the same pattern is used, for example in the "About" pages and on multisite, I think the best option would be trying to address this issue globally across the admin. It's also confusing because many plugins use the same visual pattern for tabs that are real tabs. I'd suggest to discuss this issue in the next accessibility meeting, and also evaluate the usage of aria-current.
• Instead, "Most recent", "View all", and "Search", are real tabs and they should use the ARIA tabs pattern. To my knowledge, the only implementation of aria tabs in core so far it's in the embed "sharing dialog" in the front-end. It would be great to have some new functions able to output a proper ARIA tabbed interface. I'd tend to think this should be addressed separately from this ticket.
• headings: they're great and they're also used by screen reader users to navigate content. I'd consider to make them visible (and shorter). Also for consistency with the widget screen, where there's an "Available Widgets" heading:

• about the heading on the right column, we can't use the words "Menu Settings" because there's already a "Menu Settings" at the bottom of the screen. I'd rather consider to move the existing "Menu Structure" before the right column, if that makes sense.
• the text added to the "Add to Menu" buttons is a bit too long. I'm not so sure it should be added there in the first place:

• the JavaScript part on the "Edit" links is a bit complicated. Please consider this whole screen has a "no-JS' fallback and when JavaScript is disabled, the links look this way:

• when JS is on, the aria-label gets populated with information about the menu item position, for example: {child item name}. Sub item number 2 under {parent item name}. I guess this part was implemented some years ago. The intent is good but I agree it doesn't tell users what that link does. I'd try to prepend Edit menu item: to the aria label value. These links should also use aria-expanded to communicate the state of the expandable panel. I wouldn't use “Press return or enter to open this section” at all.

Sorry for the wall of text :) In a few words, I'd suggest to split the JS part in a separate ticket and discuss the tabs/non-tabs in the next meeting.

[audrasjb]

Hi @afercia and thanks for this very interesting wall of text :)

So, I will try a simplier approach.
I will now upload several independant new diff files for each point I can fix.

[audrasjb]

"tabs" markup: replace h2 with ul>li without any aria-label attribute since this is not "real" tabs

[audrasjb]

Adds columns titles to menu screen. Bonus: adds a small hin at the top of the screen concerning data saving ;)

[audrasjb]

Columns titles rendering

[audrasjb]

Adds hints to "Add to Menu" buttons - 2nd attempt

[audrasjb]

Summary of the last attached files:

• 40678_tabs_markup.diff adds a better markup to Menu screen "tabs" (not real tabs). Replace H2 with un unordered list.
• 40678_colums_titles.diff adds columns titles to menu screen. I made a screenshot of the rendering above. Bonus: adds a small hint/disclaimer at the top of the screen concerning data saving, because users can misunderstand the fact their menu will not be saved at any time they make a change in this screen.
• 40678_addtomenu_hints.diff adds hints in screen-reader-text to "Add to Menu" buttons. The wording is shorter than in my previous patch. A separator have been added between the button visible label and the hint for better readability.

Can't wait to get your thought about this :)

Cheers,
Jb

[audrasjb]

As said during last accessibility team meeting, I'm splitting this ticket into smaller tickets to make it easier to fix step by step.

• Related: #43397 – Columns title and hint about data saving
• Related: #43398 – Tabs that are not actual tabs

[afercia]

The 5.1 release beta 1 is today. @audrasjb as you're the author of the patches on this ticket, mind to own it and punt it to the milestone you fill more appropriate? :)

[afercia]

@audrasjb sorry I'm going to punt this to 5.2 :)

[afercia]

I believe this ticket can be closed in favor of #43398. Please do feel free to reopen if I'm missing something.

[SergeyBiryukov]

Duplicate of #43398.

[javad2000]

Hi
This problem still exists after 3 years. I hope WordPresss team solves the problem ASAP via a plugin or preferrably via the core.

We need two simple comboboxes in the menu options:

Parent item and child position.

That's quite simple.
Two other suggestions:
1- The same two comboboxes might be added to page/post editor pages as well, so we can add/rearrange our page/post directly to the menu without going to the menu editor.
2- We might have the same two comboboxes when adding a new item to the menu, beside when editing a menu item.

Best Regards

Replying to juliemoynat:

Hi,

I've first created this ticket in WordPress accessibility support (​https://wordpress.org/support/topic/editing-menus-in-wp-admin-for-blind-people/) but this is not a support ticket so I re-post it here.

With a blind person, we noticed that navigate through the page to create menus with a keyboard and a screen reader is not easy. Then, I tried to help him by giving him a page description.

We noticed that :

• this page lacks titles at the top of blocks to explain what these blocks are. This would help blind people to better find each block and to navigate easily from one block to another.
• there are some masked explanations but not everywhere so, for example, he can’t imagine that clicking on links in “Menu structure” would have opened an accordion
• there are some tabs navigation (at the top: “Edit menus” and “Manage locations”, in the left column: “Most recent”, “View all”, “Search”) but blind people can’t know which one is active not either that they are tabs.

So, I think there are 2 steps to enhance editing menus in WP admin :

1. giving more informations by screen reader texts
2. using ARIA design patterns for tabs and accordions: ​https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex

For step 1, we could :

• for all tabs: add a screen reader text on the active one “(current tab)”
• for tabs at the top (“Edit menus” and “Manage locations”): remove the “h2” tag and use an unordered list (“ul”) with an “aria-label” attribute that would tell “Main tabs for editing menus”
• add a title before each block: for left column, this could be “Choose which links you want to have in your menu”, for right column, this could be “Change parameters for the links you added in your menu (order, label, title…)”
• add a screen reader text to “Add to menu” button, like “(after that, don’t forget to active “Save menu” button)”
• add a screen reader text to links in the right column (just like in the left one): “Press return or enter to open this section”
• add a screen reader text after the 2 first tabs, in a paragraph that would tell users something like “don’t forget to active “Save menu” button to save all your modifications”. So, if they don’t find that button, they could search it with their screen reader thanks to its name.

These texts would help blind people to navigate title by title and to understand how it works.

What do you think about it? Could it be added to WordPress admin?