[wp-trac] [WordPress Trac] #29158: Customizer UI Design lacks contrast for visual hierarchy and does not match wp-admin

WordPress Trac noreply at wordpress.org
Wed Oct 26 09:27:20 UTC 2016


#29158: Customizer UI Design lacks contrast for visual hierarchy and does not match
wp-admin
-------------------------------------------------+-------------------------
 Reporter:  celloexpressions                     |       Owner:  helen
     Type:  task (blessed)                       |      Status:  reviewing
 Priority:  normal                               |   Milestone:  4.7
Component:  Customize                            |     Version:  3.8
 Severity:  normal                               |  Resolution:
 Keywords:  color-contrast ui-feedback has-      |     Focuses:  ui,
  patch needs-testing                            |  accessibility
-------------------------------------------------+-------------------------

Comment (by folletto):

 > could you elaborate on why they shouldn't be the same or the border
 shouldn't be used on hover? Want to give you a chance to clarify before we
 finalize this direction.

 There are multiple reasons:

 1. Interaction — mouse and keyboard are two different input methods, and
 the fundamental interaction design paradigm of the combination of these
 modalities has at its foundation to have two different highlights to
 specify focus. Since mouse and keyboard act and move in different ways, we
 have the ability to target them independently.
 2. Weight — mouse and keyboard are inherently different. The mouse pointer
 is often enough to signify where the user is and clicks. As a reference,
 many desktop UI guidelines don't even provide a hover in many instances,
 but they ALL provide keyboard navigation. Adding a styling to `hover` is
 in many instances an extra on top of not really requiring anything, while
 adding a styling on keyboard is a fundamental requirement, and it has to
 be evident because the user doesn't know where the focus is going to jump
 in the next tabulation.
 3. Standard — the standard provides both independently for independent
 styling for the reasons above.

 There are instances where `focus` and `hover` can conflate in a single
 styling. Sometimes there are limited options, sometimes there is a need of
 higher visibility.

 In this case however we have a situation where the two aren't just
 possible, but we also already have a design that make them perfectly
 interlocking (an element can have both `focus` and `hover` and the styling
 is designed to work combining them properly — thus we have ready a
 solution that is already optimal in many ways.

 Given we are perfectly following the interaction models, and we already
 have a proper solution to deal with `focus` and `hover`, I see no reason
 to revert to a less optimal case of having the stylings conflated into
 one, unless there's a strong reason — or a better design. :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/29158#comment:101>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list