WordPress.org

Make WordPress Core

Opened 7 weeks ago

Closed 2 days ago

Last modified 2 days ago

#48409 closed defect (bug) (fixed)

Menus: form controls disabled only visually when creating a new menu

Reported by: afercia Owned by: audrasjb
Milestone: 5.3.1 Priority: normal
Severity: normal Version:
Component: Menus Keywords: has-screenshots has-patch commit
Focuses: ui, accessibility Cc:
PR Number:

Description

In the menus page, when creating a new menu the boxes on the left column get a opacity: 0.5; CSS property to "look" disabled:

http://cldup.com/rDxRyuxQqt.png

However, they're still fully actionable:

  • accordions, tabs, and all the form controls can be clicked with mouse
  • same with keyboard: everything can be navigated to and activated pressing the Enter or Spacebar keys

It worked this way since ages and it's confusing for all users. Not to mention it's a WCAG violation:

Relevant standards:
WCAG 1.3.3 Sensory Characteristics (Level A)
https://www.w3.org/TR/WCAG21/#sensory-characteristics
https://www.w3.org/WAI/WCAG21/Understanding/sensory-characteristics.html

Basically, the UI visually conveys a state that doesn't match the actual UI controls state.

A similar issue was filed for the Image Editor in the WPCampus audit, see https://github.com/WordPress/gutenberg/issues/15299. Even though the details are different, the outcome is the same.

Considerations:

  • Does the left column content need to be displayed in the first place? It could be hidden with visibility: hidden until the new menu is created.
  • If displaying the left column controls is preferred, all UI controls should be really disabled.
  • Technically, this would be a bit challenging especially for the accordions and the "tabs".
  • All the checkboxes and input fields could use a disabled HTML attribute but it should be set via JavaScript and the implementation looks a bit overkill at a first glance.
  • Overall, I'd personally lean towards using visibility: hidden on the whole left column content.

Additionally, [46240] changed the "Select All" from a link to a checkbox + label.
Previously, when creating a new menu, the link was hidden. Now, only the checkbox is hidden but the label stays visible:

http://cldup.com/-jVb1Hhmzo.png

Attachments (5)

Capture d’écran 2019-11-17 à 11.30.11.png (91.9 KB) - added by audrasjb 3 weeks ago.
Hidden visually
fa5a30455ff6da86226d59e66dc0128f.gif (717.9 KB) - added by audrasjb 3 weeks ago.
Animation to show the behavior when creating a new menu
48409.patch (599 bytes) - added by sathyapulse 3 weeks ago.
48409.patch
48409.1.diff (591 bytes) - added by simonjanin 3 weeks ago.
48409.2.diff (6.0 KB) - added by SergeyBiryukov 2 weeks ago.

Download all attachments as: .zip

Change History (19)

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


5 weeks ago

#2 @afercia
5 weeks ago

  • Keywords needs-design-feedback added
  • Milestone changed from Awaiting Review to 5.3.1

#3 @dinhtungdu
5 weeks ago

This ticket has been discussed during the bug scrub and we agreed to try it for 5.3.1.

The solution using visibility: hidden had received the highest votes and the team wants to ask for a design feedback for it.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 weeks ago

@audrasjb
3 weeks ago

Animation to show the behavior when creating a new menu

#5 @audrasjb
3 weeks ago

  • Keywords needs-design-feedback removed
  • Owner set to audrasjb
  • Status changed from new to accepted

Hi,

Removing needs-design-feedback thanks to @dinhtungdu.

I tested visibility: hidden and it looks like a nice compromise to me.
Proposed patch in nav-menus.css:

.metabox-holder-disabled {
	visibility: hidden;
}

We’ll also need remove the old CSS opacities.

@sathyapulse
3 weeks ago

48409.patch

#6 @audrasjb
3 weeks ago

  • Keywords has-patch needs-testing added

@simonjanin
3 weeks ago

#7 @audrasjb
3 weeks ago

  • Keywords needs-testing removed

Thanks for the patch @sathyapulse
unfortunately, it doesn't apply cleanly. You have to generate it from wordpress-develop. But thanks for showing the good way to handle that issue 👏

Thanks for the patch @simonjanin, looks go to go on my side.

#8 @audrasjb
3 weeks ago

  • Keywords commit added

Adding commit keyword. 48409.1.diff addresses the regression.

Last edited 3 weeks ago by audrasjb (previous) (diff)

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


3 weeks ago

#10 in reply to: ↑ description @SergeyBiryukov
2 weeks ago

Replying to afercia:

All the checkboxes and input fields could use a disabled HTML attribute but it should be set via JavaScript and the implementation looks a bit overkill at a first glance.

Just noting that we already have wp_nav_menu_disabled_check() for disabling "Add to Menu" submit buttons there, so disabling all the other checkboxes and input fields seems as simple as 48409.2.diff.

Would that solve the issues here, except for accordions and tabs still being clickable?

If that still causes confusion or doesn't address all the issues, then I have no objections to 48409.1.diff, other than leaving a weird empty space on the left, but that seems like a fair compromise.

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


8 days ago

#12 @welcher
8 days ago

This was discussed in the bug scrub and the consensus was that removing the box felt strange and might cause some visual friction for users.

As such, we decided to go with patch provided by @SergeyBiryukov. Great work all!

Last edited 8 days ago by welcher (previous) (diff)

#13 @SergeyBiryukov
2 days ago

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

In 46842:

Accessibility: Menus: Properly disable form controls on the Menus screen that cannot be used until at least one menu is created.

This ensures that the actual UI controls state matches the visually conveyed state.

Props afercia, audrasjb, dinhtungdu, sathyapulse, simonjanin, welcher, SergeyBiryukov.
Fixes #48409.

#14 @SergeyBiryukov
2 days ago

In 46843:

Accessibility: Menus: Properly disable form controls on the Menus screen that cannot be used until at least one menu is created.

This ensures that the actual UI controls state matches the visually conveyed state.

Props afercia, audrasjb, dinhtungdu, sathyapulse, simonjanin, welcher, SergeyBiryukov.
Merges [46842] to the 5.3 branch.
Fixes #48409.

Note: See TracTickets for help on using tickets.