Incorrect cursor used on buttons

[nrqsnchz]

Moved from the ​WPCampus accessibility report issues on GitHub. ​Issue #15343

Severity: Low

Affected Populations:

• Low-Vision
• Cognitively Impaired

Platform(s):

• All / Universal

Components affected:
-Global

Issue description

Buttons throughout the application use the pointer cursor instead of the
default.

The use of consistent and relevant cursors may be important for users
who have a cognitive disability, since cursors give a visual clue as to
an element's functionality. Using the pointer cursor for elements which
do not typically show that cursor may be confusing or counter-intuitive
for users.

Issue Code

label {
    cursor: pointer;
}

.wp-core-ui .button,
.wp-core-ui .button-primary,
.wp-core-ui .button-secondary {
    cursor: pointer;

    ...

}

input[type=checkbox],
input[type=radio] {
    cursor: pointer;

    ...

}

.components-button {
   cursor: pointer;

    ...

}

Remediation Guidance
Only controls that navigate users to new pages/views should have the
cursor set to pointer, while controls performing push-button type
actions use default.

Recommended Code

label {
 cursor: default;
}

.wp-core-ui .button,
.wp-core-ui .button-primary,
.wp-core-ui .button-secondary {
    cursor: default;

    ...

}

input[type=checkbox],
input[type=radio] {
    cursor: default;


    ...

}

.components-button {
   cursor: default;

    ...

}

References

​https://www.w3.org/TR/CSS22/ui.html#cursor-props

Note: This issue may be a duplicate with other existing accessibility-related bugs in this project. This issue comes from the Gutenberg accessibility audit, performed by Tenon and funded by WP Campus. This issue is GUT-9 in Tenon's report

[nrqsnchz]

Screenshot example of incorrect cursor

[nrqsnchz]

Screenshot example of incorrect cursor

[nrqsnchz]

Quoting comments from the GitHub Issue:

@afercia

Same for all the <label> elements and buttons in core:

@getdave

Does this need changing or are we sticking with the pattern established in WP Core?

afercia

For full compliance, it should be changed. I guess it needs be discussed by the accessibility and design teams.

@kjellr

That's interesting! I've never known this was specifically against a11y guidelines. In general on the web, I tend to expect that most "clickable" elements use a pointer cursor (take the buttons here on GitHub for instance, which have a cursor: pointer rule). I'd love to have more discussion around this.

afercia

Interesting issue, indeed. I don't think this is explicitly mentioned anywhere in the WCAG (I may be wrong). However, it has more to do with operating systems / browsers default: they shouldn't be changed unless there are very, very, good reasons to do so.

The native cursor style for buttons is default: ​https://codepen.io/afercia/full/EzjXMo

The W3C spec (CSS 2.2) linked above (​https://www.w3.org/TR/CSS22/ui.html#cursor-props) clearly states:

pointer: The cursor is a pointer that indicates a link.

Same for CSS3 UI: ​https://www.w3.org/TR/css-ui-3/#cursor

The rationale is that pointer should be reserved for links, to help users differentiate UI controls that trigger navigation from buttons and the like. Granted, in WordPress you never know whether what are you going to click is a button or a link For historical reasons, sometimes links are styled as buttons, and buttons are styled as links. Ideally, this shouldn't happen. Links should be clearly identified as links. Buttons should be identified as buttons.

After some software archeology, turns out some of the related changes are very ancient:

<label> elements got their cursor: pointer 15 years ago in: https://core.trac.wordpress.org/changeset/560 no related Trac ticket.

<button> elements 11 years ago in: https://core.trac.wordpress.org/changeset/7215 related Trac ticket: https://core.trac.wordpress.org/ticket/5943

[kjellr]

To reiterate some of what's noted in the GitHub ticket:

As @afercia noted, WP buttons are not consistent in their behavior: some of them act as links, while others act as traditional button elements. The fully-compliant fix for this would be to:

1. Remove the pointer cursor from our button styles.
2. Do an audit of buttons throughout WP-Admin.
3. Change buttons that act as links to be links instead of buttons.

That said, this ticket is interesting in that the W3C guideline goes against what many users anticipate: if something is clickable, they expect to see a pointer icon when hovering over it. The visual appearance of a button may remediate that though, so I'm not 100% sure what the best solution is here. It sounds like the WCAG guidelines do not specify this behavior exactly.

[boemedia]

I think a button inventory would be a good first start. Maybe if we have everything in place, someone from the accessibility team can help make a decision on how to move forward.

For whoever picks up the inventory, this website is a good starting point if you like more information on how to do an inventory: ​http://bradfrost.com/blog/post/interface-inventory/

[sabernhardt]

Here is a start on the interface inventory:
​https://docs.google.com/spreadsheets/d/1GTyJ2nD3zaRXijyHfmKcu3JcnzLZiBhS7X74u-0z-WI/edit?usp=sharing

I ran a search on every use of the word "cursor" in WP 5.2.3, including instances related to the block editor and bundled themes. Then I filtered out any variable names, comments, minified and right-to-left versions, etc... To make it easier to read and/or to see what was filtered out (note the Ignore column), you can download the file.

Anyone can add comments to the sheet; however, editors will need to request an invite.

According to the discussion above, anywhere that has only the button element and "pointer" specified as the cursor should either have that line removed or replaced with "default" for the cursor property. For now, I only entered one change recommendation where I think the help cursor would be better than default (help buttons on the Image Edit screen).

[karmatosed]

Noting I removed myself as an assigned person because @sabernhardt was awesome and created a sheet to start on inventory. I will be totally supporting with feedback but no need to have it sitting with me.

[melchoyce]

That said, this ticket is interesting in that the W3C guideline goes against what many users anticipate: if something is clickable, they expect to see a pointer icon when hovering over it.

I agree with Kjell — as a user, I expect that any interactive element will use the "pointer" cursor. Interactivity on the web has changed a lot in the past decade, and people have been using pointers on anything that looks like a button for so long (maybe because we started styling link tags like button once CSS was mainstreamed, I don't know) that the original intent has been superseded the learned behavior of "pointer = I can click this."

Since the argument is around using consistent and relevant cursors as to benefit users with cognitive disabilities, I'd actually argue that WordPress dropping the pointer from buttons actually goes against the intent of the spec, because we'd be using buttons inconsistently from much of the web. Having a pointer also makes it more clear when a button is disabled, because disabled buttons shouldn't have the pointer cursor. I think this is a case where a browser default hasn't caught up with modern web practices.

[johnbillion]

I agree with the above. Removing pointer cursors from clickable non-link elements seems to go against the spirit of the guideline, even if it adheres to its exact wording.

As noted above, the more fundamental fix is to ensure that links and buttons are correctly used depending on the action being performed, rather than removing the cursor pointer from non-links.

[afercia]

Related: ticket:48463#comment:5 and following comments.

[drw158]

I tend to agree with @melchoyce and others. For better or worse, much of the web has deviated from the default cursor behavior. I don't have any research to prove this, but it's reasonable to assume that users expect to see the pointer(hand) cursor on anything that you can interact with.

Interestingly, I found this comment on the history of cursors, buttons, and links. ​https://href.li/?https://ux.stackexchange.com/a/105098

Apparently, buttons didn't need the pointe cursor because they were skeuomorphic and looked like physical buttons. Links needed the pointer cursor to indicate clickability.

I'd argue that now, on the web, there are many things on a site that are interactive that are not skeuomorphic and not necessarily links. Therefore, they need the pointer to help communicate its interactivity. For example, input labels, menu items, and cards. Input labels seem particularly problematic because usually they don't even have hover states.

---

On the other hand, we should have good hover states for interactive elements, so it less problematic over which cursor is shown.

Unless we can do some further testing on this somehow, I think this is a case where we need an executive decision and document it.

[karmatosed]

As this has design feedback, going to loop out design to leave to accessibility team to make decision.

[sabernhardt]

Some questions for discussion:

1. Do we want to change the cursor style from "pointer" for all (enabled) buttons?
2. Should the style be changed to "default" or would we simply remove the "pointer" styles?
3. Do we want to extend that to div and td elements with role=button and/or similar?
4. Should disabled buttons' cursor style be changed from "default" to something else?
5. How would we address the selectors that match both links and buttons?
6. Could someone check the highlighted question marks to identify which elements receive those styles? (at least verifying that there is no need to change)
7. I noticed one help button (and marked it in the Recommendations column). Would we want to make a change the cursor style to "help", or should we stick to "default" only (or else removal)?
8. Who would like to create a patch and/or Gutenberg pull request?

If the answer to question 1 is yes, I probably can update the spreadsheet over the next week to reflect the current version.

[nataliemac]

The Accessibility team discussed this in our meeting today and this is our recommendation:

The CSS cursor styles currently applied to button elements should be removed so the cursor can return to the browser default. We recommend just remove the CSS setting the cursor rather than explicitly setting the cursor to default. Affordance for buttons can be communicated in another way with a noticeable hover/focus style.

The pointer cursor should be reserved for links. From the WP Campus report "controls that navigate users to new pages/views should have cursor set to pointer". The intention of the pointer cursor is to help users differentiate between controls that trigger navigation to a new page/view and controls that perform other functions.

Ensuring that links and buttons are used appropriately throughout the UI is a separate issue that we'll be looking into.

[Kelderic]

Replying to nataliemac:

The Accessibility team discussed this in our meeting today and this is our recommendation:

The CSS cursor styles currently applied to button elements should be removed so the cursor can return to the browser default. We recommend just remove the CSS setting the cursor rather than explicitly setting the cursor to default. Affordance for buttons can be communicated in another way with a noticeable hover/focus style.

The pointer cursor should be reserved for links. From the WP Campus report "controls that navigate users to new pages/views should have cursor set to pointer". The intention of the pointer cursor is to help users differentiate between controls that trigger navigation to a new page/view and controls that perform other functions.

Ensuring that links and buttons are used appropriately throughout the UI is a separate issue that we'll be looking into.

Whatever the original intent of the spec was, the reality is that most websites now use the pointer cursor to indicate that something can be clicked on / interacted with. That is what users expect.

Examples:

Microsoft:

• ​https://microsoft.qualtrics.com/jfe/form/SV_4GwB58d2AZFC7o9 - Span element, used as part of a toggle that clearly isn't a link. Microsoft uses a pointer cursor.

Apple:

• ​https://www.apple.com/contact/feedback.html Select element that is clearly not a link, but Apple uses a pointer cursor.

Google:

• The main compose button on Gmail. It's a button, and it's not linking anywhere. And it uses a pointer cursor.

• Account Settings: ​https://myaccount.google.com/contacts - Google uses a pointer cursor on two way toggles.

Dell:

• Every Dell page has a special "Chat or Call" button. It uses a pointer cursor, but is not a link.

GitHub:

• On every repo page, there is a Branch Switch button that triggers a drop down menu. This is styled with a pointer cursor. Same with the Star, Fork, Used By, etc etc buttons.

Stack Overflow:

• Top menu has dropdown icon buttons. They use pointer cursors.

Reddit:

• Main Profile dropdown menu trigger button .... uses a pointer cursor.

---

I can go on and on with examples of major sites that all use the pointer cursor on non-links. It's what users expect. Removing it is going to confuse users.

[audrasjb]

Moving this ticket to 5.5 as there is still no patch/decision and WP 5.4 Beta 1 is planned in a couple of days.

[afercia]

This ticket was discussed during last week's accessibility bug-scrub. Agreed to move it to Future Release, for now. Although the cursor property usage is not conforming to the CSS spec, we tend to think the harm is minor and affects a small group of users. Concluded it's not worth fixing for now, especially because in the WordPress UI there's no clear distinction between buttons and links. Often, links are styled as buttons and they should get the pointer cursor. Instead, buttons styled as buttons should not. There are also buttons styled as links. Fixing the cursor style now may introduce even more confusion.