[wp-trac] [WordPress Trac] #47171: Incorrect cursor used on buttons
WordPress Trac
noreply at wordpress.org
Tue Nov 5 16:12:22 UTC 2019
#47171: Incorrect cursor used on buttons
-------------------------------------------------+-------------------------
Reporter: nrqsnchz | Owner: (none)
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 5.4
Component: Administration | Version:
Severity: normal | Resolution:
Keywords: has-screenshots needs-design- | Focuses: ui,
feedback wpcampus-report | accessibility
-------------------------------------------------+-------------------------
Comment (by 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.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/47171#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list