Make WordPress Core

Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#35374 closed defect (bug) (fixed)

Remove title attributes and other improvements for the Menus screen

Reported by: afercia's profile afercia Owned by: afercia's profile afercia
Milestone: 4.5 Priority: normal
Severity: normal Version: 4.4
Component: Menus Keywords: has-screenshots, has-patch, title-attribute
Focuses: ui, accessibility, javascript Cc:


On the Menus screen, some input fields have title attributes that are then used via JavaScript as visible placeholders, changing on the fly their value attribute.

The menu name and "Quick Search" fields:

Please notice that since focus is automatically moved to these fields, it's almost useless to have a "placeholder" that gets removed on focus.

I'd say that visually, there's no need for these title attributes/placeholders because the fields purpose is clear enough from the context. The menu name, when creating a new menu, has also a description below that further clarifies:

The "Quick Search" fields just need a label (hidden with screen-reader-text). Also, users already clicked on the "Search" tab so it's clear what the input field purpose is.

About the custom link fields:

I'd say they're clear enough and there's no need for the "Menu Item" title/placeholder.

Finally, the menu items in a menu have title attributes that get updated when users reorder the items:

I'd propose to replace them with aria-label attributes. Sighted users can actually see the items new position. Screen reader users will benefit from the aria labels announcing the new position.

This would also allow to completely remove wpNavMenu.setupInputWithDefaultTitle() and there's room for further improvements:

  • add missing labels and improve the existing ones
  • target the "Create new menu" field description with an aria-describedby attribute
  • the "custom links" labels and inputs should be updated also in the Customizer, solving also a CSS alignment issue
  • introduce a generic, reusable, .wp-initial-focus CSS class to be used for the sole purpose of setting the initial focus
  • "Quick Search": uniform the attached events, see comment 59 on ticket 26600
  • "Quick Search": avoid new AJAX requests to be triggered when the key pressed (e.g.arrows) doesn't change the searched term

Attachments (3)

35374.patch (16.0 KB) - added by afercia 8 years ago.
35374.2.patch (16.4 KB) - added by afercia 8 years ago.
35374.3.patch (1.1 KB) - added by afercia 8 years ago.

Download all attachments as: .zip

Change History (12)

8 years ago

#1 @afercia
8 years ago

  • Keywords has-screenshots has-patch added
  • Owner set to afercia
  • Status changed from new to assigned

First pass. Some testing and review would be nice :)

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

8 years ago

8 years ago

#3 @afercia
8 years ago

Refreshed patch to use feature detection to determine whether inputs should use the keyup or input event. See [34078]. This should probably be abstracted a bit and used in more places. cc @ocean90 @azaozz

#4 @azaozz
8 years ago

This should probably be abstracted...

It can be abstracted but the test for the input event is so simple/small, not sure it's worth it having it as a function :)

35374.2.patch looks and works well.

#5 @afercia
8 years ago

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

In 36379:

Accessibility: Remove title attributes from the Menus screen.

Also, adds missing labels and improves the existing ones.
Updates the "custom links" labels and inputs in the Customizer too.
Introduces a generic, reusable, .wp-initial-focus CSS class to be used for
the sole purpose of setting the initial focus.
"Quick Search": uniform the attached events and avoids new AJAX requests to
be triggered when the pressed key doesn't change the searched term.

Fixes #35374.

#6 @afercia
8 years ago

  • Keywords needs-patch added; has-patch removed
  • Resolution fixed deleted
  • Status changed from closed to reopened

With the change about the quick search field events, in modern browsers it is now possible to submit the form pressing Enter on the search field. Form submission should now be prevented on the form submit event or maybe just always attach both input and keyupon the search field for all browsers.

#7 @afercia
8 years ago

  • Keywords has-patch added; needs-patch removed

The new patch prevents form submission on the submit form event. Also, the check for the Enter key doesn't make much sense now. Modern browsers will use the input event which doesn't have keys-related properties to check. Legacy browsers will use the keyup event which triggers the search for any key press.

8 years ago

#8 @afercia
8 years ago

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

In 36426:

Menus: after [36379] prevent "Quick Search" form submission when pressing Enter.

Fixes #35374.

#9 @afercia
7 years ago

  • Keywords title-attribute added
Note: See TracTickets for help on using tickets.