Make WordPress Core

Opened 9 months ago

Closed 6 months ago

Last modified 4 months ago

#59733 closed defect (bug) (fixed)

Disabled form controls should not use cursor: pointer

Reported by: afercia's profile afercia Owned by: afercia's profile afercia
Milestone: 6.5 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots has-patch needs-dev-note
Focuses: ui, accessibility, css Cc:

Description (last modified by afercia)

Traditionally, WordPress sets the CSS property cursor: pointer for all form controls and their <label> elements. That is a non-native styling, as by default form controls and labels use the default pointer. Anyways, long time ago it was decided to use the pointer value to highlight the form controls are 'interactive' elements.

However, there is a problem when some form controls are disabled or have an aria-disabled="true" attribute: they still show a pointer cursor, which just feels wrong for disabled controls.

This appears particularly true for checkboxes and radio buttons but all other form controls should be checked.

I couldn't find many cases of disabled checkboxes and radio buttons in core and there's probably a reason: traditionally, WordPress doesn't disable settings, it hides them instead. However, there are a few cases and the Gutenberg editor does use to render disabled controls.

This problem should be first be addressed in the core stylesheets and then addressed in the Gutenberg repository as well. I will create a GitHub issue for that.

A couple ways to reproduce:

  • Install and activate the Link Manager plugin: https://wordpress.org/plugins/link-manager/
  • Add a new link.
  • In the form to create a new link, check the checkbox another web address of mine
  • Observe all the following checkboxes and radio buttons get disabled.
  • Hover the mouse on the disabled checkboxes and radio buttons.
  • Observe they all display the 'pointer' cursor despite the fact they are disabled.
  • Edit a post.
  • Add an Image block and add a link to the image.
  • While the block is selected, observe the lightbox setting in the settings sidebar.
  • Observe the toggle to enable the lightbox 'Expand on Click` is disabled.
  • Hover the mouse on the toggle and observe the displayed cursor is 'pointer'.

Attachments (7)

disabled controls core.png (130.4 KB) - added by afercia 9 months ago.
Disabled controls in the Link Manager plugin user interface
disabled controls gutenberg.png (23.7 KB) - added by afercia 9 months ago.
Disabeld controls in the editor user interface
reading settings.png (66.2 KB) - added by afercia 9 months ago.
59733.diff (2.6 KB) - added by afercia 9 months ago.
59733.2.diff (2.3 KB) - added by afercia 9 months ago.
59733.3.diff (2.6 KB) - added by afercia 9 months ago.
Test Add New Link RC-2.mp4 (905.5 KB) - added by mainetenance 4 months ago.
Add new link cursor behavior

Download all attachments as: .zip

Change History (26)

@afercia
9 months ago

Disabled controls in the Link Manager plugin user interface

@afercia
9 months ago

Disabeld controls in the editor user interface

#1 @afercia
9 months ago

  • Description modified (diff)

#2 @afercia
9 months ago

  • Owner set to afercia
  • Status changed from new to assigned

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


9 months ago

#4 @joedolson
9 months ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 6.5

#5 @afercia
9 months ago

One more (long standing) case where the labels of disabled form controls still display the pointer cursor is in the Reading Settings. See screenshot below.

@afercia
9 months ago

#6 @afercia
9 months ago

59733.diff is a proof of concept to illustrate what are the challenges for this apparently simple task.

Inputs and select elements are pretty simple to address.
Instead, the label elements are a little more challenging.

  • Wrapping labels are pretty simple to address. The patch uses the :has() functional CSS pseudo-class to target <label> elements that wrap a disabled form control. As far as I can tell this should work in all cases, as a label is supposed to contain only one form control. It's the first time core would use :has(), but it is already used in the Gutenberg editor.
  • The challenge is with non-wrapping labels associated with for / id attribute:
    • They could be before the form control (e.g. for text inputs).
    • They could be after the form control (e.g. for radio buttons and checkboxes).
    • They could be not immediately adjacent to their associated form control.
    • They could be preceded or followed by _other_ disabled form controls or labels.

I couldn't think of a solid way to target with CSS all non-wrapping labels of disabled controls. Any thoughts more than welcome.

#7 @afercia
9 months ago

For some historical context:

<label> elements got the cursor: pointer 20 years ago in [560]
no related Trac ticket.

<button> elements 16 years ago in [7215]
related Trac ticket: #5943

#8 @afercia
9 months ago

Four years ago the Gutenberg accessibility audit reported an issue about incorrect usage of the cursor pointer on buttons (and labels). See https://github.com/WordPress/gutenberg/issues/15343 and #47171.

It is true that with native HTML/CSS browsers don't display a pointer cursor on any form element and label. If you are curious, you can for example have a look at Firefox's user agent stylesheet for form elements by entering this in your Firefox address bar: resource://gre-resources/forms.css. The only form element that gets a cursor: pointer is input[type=image]. Browers reserve the pointer cursor for links.

That said, WordPress and other web applications set cursor: pointer; for form elements and labels to highlight they are 'interactive' elements. While that's non standard, I'd tend to recognize some value in doing that for form controls. However, given it's impossible to reliably reset the default cursor for labels of disabled controls, I'd like to propose to entirely remove the pointer cursor for label elements and only keep it for form controls. I'd think this is a good balance as nothing would change for inputs, selects, buttons etc.

Worth also noting that there is an inconsistency between the styling of disabled select elements and the one for disabled radio buttons / checkboxes:

  • Disabled select: the cursor is reset to default.
  • Disabled radio buttons and checkboxes: the cursor is not reset to default.

I'd call this a bug as there is no reason to make disabled form controls behave differently.

@afercia
9 months ago

#9 @afercia
9 months ago

  • Keywords has-patch added; needs-patch removed

59733.2.diff is the simplest approach:

  • Entirely removes cursor: pointer; for label elements.
  • Targets [aria-disabled="true"] for all the existing 'disabled' cases where the cursor is already reset to default.

#10 @afercia
9 months ago

Test instructions:

  • Go to Settings > Reading Settings
  • Make sure 'Your homepage displays' is set to 'Your latest posts'.
  • Hover the mouse on the 'Homepage:' and 'Posts page:' disabled select elements.
  • Observe the mouse cursor is the default one.
  • Hover the mouse on the disabled select elements labels.
  • Observe the mouse cursor is the default one.
  • Install and activate the Link Manager plugin: https://wordpress.org/plugins/link-manager/
  • Add a new link.
  • In the form to create a new link, check the checkbox another web address of mine.
  • Observe all the following checkboxes and radio buttons get disabled.
  • Hover the mouse on all radio boxes, checkboxes, and their labels.
  • Observe the mouse cursor is always the default one.

@afercia
9 months ago

#11 @afercia
9 months ago

59733.3.diff also removes cursor: pointer; for the label element in the install.css stylesheet.

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


7 months ago

#13 @joedolson
6 months ago

  • Keywords commit added

Tested, and this behaves as described. I think this is a good change; it's a good compromise between the specifications and real world usage and expectations.

Recommend for commit.

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


6 months ago

#15 @afercia
6 months ago

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

In 57520:

Administration: Accessibility: Use the default cursor style for labels and disabled form controls.

The native cursor style for labels and form controls is default, which is the platform-dependent default cursor. Typically an arrow. Historically, WordPress always used the pointer style for all form controls and labels. While this isn't standard, there is some value in using the pointer style for form controls. However, labels should use the default style especially when the associated controls are disabled.
Additionally, makes sure the disabled styling works for form controls with an aria-disabled="true" attribute.

Props joedolson, afercia.
Fixes #59733.

#16 @afercia
6 months ago

  • Keywords commit removed

#17 @Cybr
6 months ago

I immediately noticed this change on a development site and thought there was some odd plugin conflict.

I agree with the change, but it felt like something was broken.

#18 @afercia
6 months ago

  • Keywords needs-dev-note added

Thabks @Cybr for your feedback. Then I'd say it's important to consider this change for a dev note in the next release Field Guide.

@mainetenance
4 months ago

Add new link cursor behavior

#19 @mainetenance
4 months ago

Tested using the instructions listed in the call for testers. The cursor behavior for Add New Link labels is not the same as the disabled checkboxes. The other steps however appear correctly as default.

Note: See TracTickets for help on using tickets.