Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect cursor used on buttons #15343

Closed
karlgroves opened this issue Apr 30, 2019 · 9 comments
Closed

Incorrect cursor used on buttons #15343

karlgroves opened this issue Apr 30, 2019 · 9 comments
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.

Comments

@karlgroves
Copy link

Incorrect cursor used on buttons

  • 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

@gziolo gziolo added the Needs Accessibility Feedback Need input from accessibility label Apr 30, 2019
@afercia afercia added Needs Design Feedback Needs general design feedback. [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). and removed Needs Accessibility Feedback Need input from accessibility labels May 4, 2019
@afercia
Copy link
Contributor

afercia commented May 4, 2019

Worth noting this is a "feature" used across all the WordPress admin. Gutenberg uses its own cursor: pointer rule, and in other cases the same property is inherited by the core CSS.

@melchoyce
Copy link
Contributor

Screenshots from full report:

image

image

@afercia
Copy link
Contributor

afercia commented May 5, 2019

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

Screenshot 2019-05-05 at 14 08 46

Screenshot 2019-05-05 at 14 08 54

@getdave
Copy link
Contributor

getdave commented May 6, 2019

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

@afercia
Copy link
Contributor

afercia commented May 6, 2019

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

@kjellr
Copy link
Contributor

kjellr commented May 7, 2019

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.

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
Copy link
Contributor

afercia commented May 7, 2019

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

@enriquesanchez
Copy link
Contributor

Discussed today during the design's team Gutenberg triage in Slack.

Created Trac ticket: https://core.trac.wordpress.org/ticket/47171 for follow up.

@mapk
Copy link
Contributor

mapk commented May 7, 2019

I'm going to close this in favor of a more holistic Core approach. Thanks for creating a ticket in Trac, @enriquesanchez!

@mapk mapk closed this as completed May 7, 2019
@gziolo gziolo added [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked. and removed Needs Design Feedback Needs general design feedback. labels May 8, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). [Type] WP Core Ticket Requires an upstream change from WordPress. Core Trac ticket should be linked.
Projects
None yet
Development

No branches or pull requests

8 participants