WordPress.org

Make WordPress Core

Opened 3 months ago

Last modified 28 hours ago

#47171 assigned defect (bug)

Incorrect cursor used on buttons

Reported by: nrqsnchz Owned by: karmatosed
Milestone: 5.3 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots needs-design-feedback wpcampus-report
Focuses: ui, accessibility, coding-standards Cc:

Description

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

Attachments (2)

57185725-74281380-6e85-11e9-9834-56c0c6507e1b-1.png (241.9 KB) - added by nrqsnchz 3 months ago.
Screenshot example of incorrect cursor
57185727-7a1df480-6e85-11e9-8ce9-c8a68be9d7a3.png (128.5 KB) - added by nrqsnchz 3 months ago.
Screenshot example of incorrect cursor

Download all attachments as: .zip

Change History (13)

@nrqsnchz
3 months ago

Screenshot example of incorrect cursor

@nrqsnchz
3 months ago

Screenshot example of incorrect cursor

#1 @nrqsnchz
3 months ago

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 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 if 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

Last edited 3 months ago by nrqsnchz (previous) (diff)

#2 @afercia
3 months ago

  • Keywords has-screenshots needs-design-feedback added

#3 @afercia
3 months ago

  • Component changed from General to Administration

#4 @afercia
3 months ago

  • Keywords wpcampus-report added
  • Milestone changed from Awaiting Review to 5.3

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


2 months ago

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


8 weeks ago

#7 @kjellr
8 weeks ago

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.

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


7 weeks ago

#9 in reply to: ↑ 8 @boemedia
7 weeks ago

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/

#10 @karmatosed
3 weeks ago

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

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


28 hours ago

Note: See TracTickets for help on using tickets.