#59733 closed defect (bug) (fixed)
Disabled form controls should not use cursor: pointer
Reported by: |
|
Owned by: |
|
---|---|---|---|
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 )
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)
Change History (26)
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
16 months ago
#5
@
16 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.
#6
@
16 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.
#8
@
16 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.
#9
@
16 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 todefault
.
#10
@
16 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.
#11
@
16 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.
14 months ago
#13
@
13 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.
13 months ago
#17
@
13 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
@
12 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.
#19
@
11 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
.
Disabled controls in the Link Manager plugin user interface