Make WordPress Core

Opened 5 years ago

Closed 4 years ago

#35578 closed defect (bug) (fixed)

Improve the Menus screen "move" links

Reported by: afercia Owned by: afercia
Milestone: 4.7 Priority: normal
Severity: normal Version:
Component: Menus Keywords: has-screenshots has-patch
Focuses: ui, accessibility Cc:


In the Menus screen, items in a menu can be moved to up, down, under other items, etc. The "move" links are currently just a list of "non links" (with a # as value of the href attribute) and they're wrapped in label element.


These links are not available when JavaScript is off so they should be marked up as buttons because they behave like buttons. The new button-link CSS class would be handy for this.

Additionally, they shouldn't be wrapped inside a label element and probably be in a list, since this is a list of available, logically grouped, actions.

Attachments (2)

35578.patch (2.6 KB) - added by Cheffheid 5 years ago.
35578.diff (3.8 KB) - added by afercia 4 years ago.

Download all attachments as: .zip

Change History (14)

#1 @afercia
5 years ago

  • Keywords ui-feedback added

and probably be in a list

Or maybe within a fieldset with a hidden legend. Also, not sure why labels and link text should be italic, seems against WordPress conventions to me. Usually italic is used for additional, descriptive, text (like hints or suggestions, see the .howto CSS class) and not for labels or links.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

5 years ago

5 years ago

#3 @Cheffheid
5 years ago

  • Keywords has-patch added; needs-patch removed

A first pass, which replaces the paragraph tag with a fieldset. Reworks the "Move" span into a legend. Replaces the anchors with buttons. And removes the wrapping label (it was causing some hover issues with the buttons anyway :)).

Also includes some CSS to make it look like it did before.

#4 @Cheffheid
5 years ago

Adding this here too: #36553

It's a mini-proposal for adding an extension to button-link for use on links like these so we're not adding a bunch of same-y colour CSS all over the place.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

#6 @afercia
4 years ago

  • Milestone changed from Awaiting Review to 4.7

Let's try this for 4.7 :)

#7 @Cheffheid
4 years ago

Patch doesn't seem to be in need of a refresh. Should be good to go for review and further testing. :)

#8 @afercia
4 years ago

@Cheffheid thanks very much for the patch 🙂 tested a bit and worth considering the combined effect of the new <legend> text with the buttons aria-label. When tabbing through the buttons, screen readers repeat the legend for each control in the fieldset so they read for example: "Move down one, button, Move this menu item" where the first part is the aria label text and the second part is the legend text:


Wondering what to do here: try to find a better legend text? Remove the legend? Maybe worth discussing a bit this in the weekly accessibility meeting!

Aside: I'd consider to add type="button" to all the buttons and then remove the event and preventDefault() from the JS part.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

4 years ago

This ticket was mentioned in Slack in #core by stevenkword. View the logs.

4 years ago

4 years ago

#11 @afercia
4 years ago

  • Keywords ui-feedback removed
  • Owner set to afercia
  • Status changed from new to assigned

Refreshed patch.

  • removes the legend and hides the "Move" span from assistive technologies: the aria-label attributes already add "Move" to each button
  • adds type="button" and removes e.preventDefault()
  • updates a jQuery selector
  • adds box-shadow to the focus style

#12 @afercia
4 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 38770:

Accessibility: Improve the UI controls to move the Menu items.

On the Menus screen, the links to move menu items behave like buttons: they
perform an action so they should be real buttons to be correctly reported to
assistive technologies. Since they're logically grouped controls, they should
also be wrapped in a <fieldset> element for better semantics and accessibility.

Props Cheffheid.
Fixes #35578.

Note: See TracTickets for help on using tickets.