#48409 closed defect (bug) (fixed)
Menus: form controls disabled only visually when creating a new menu
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.3.1 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Menus | Keywords: | has-screenshots has-patch commit |
Focuses: | ui, accessibility | Cc: |
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:
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:
Attachments (5)
Change History (19)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
5 years ago
#2
@
5 years ago
- Keywords needs-design-feedback added
- Milestone changed from Awaiting Review to 5.3.1
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#5
@
5 years 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.
#7
@
5 years 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
@
5 years ago
- Keywords commit added
Adding commit
keyword. 48409.1.diff
addresses the regression.
This ticket was mentioned in Slack in #accessibility by audrasjb. View the logs.
5 years ago
#10
in reply to:
↑ description
@
5 years 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.
5 years ago
#12
@
5 years 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 @SergeyBiryukov patch. Great work all!
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.